XEP-0434: Trust Messages (TM)

Abstract
This document specifies a way to communicate the trust in public long-term keys used by end-to-end encryption protocols from one endpoint to another.
Author
Melvin Keskin
Copyright
© 2020 – 2021 XMPP Standards Foundation. SEE LEGAL NOTICES.
Status

Experimental

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems are advised to carefully consider whether it is appropriate to deploy implementations of this protocol before it advances to a status of Draft.
Type
Standards Track
Version
0.6.0 (2021-10-04)
Document Lifecycle
  1. Experimental
  2. Proposed
  3. Stable
  4. Final

1. Introduction

End-to-end encryption without verifying the authenticity of the exchanged public long-term keys only enables the endpoints to protect their communication against passive attacks. This means an attacker cannot read encrypted messages in transit without actively intervening in the key exchange. However, without any other precautions, active attacks are still possible. If an attacker replaces the exchanged keys with malicious ones or introduces an additional malicious endpoint, the end-to-end encrypted messages can be read and manipulated by the attacker.

When using end-to-end encryption where public long-term keys are transmitted over a channel that is not protected against active attacks, the authenticity of those keys is not guaranteed. Such a key has to be authenticated by the receiving endpoint over another channel that is already protected against active attacks to maintain the confidentiality of sent messages and ensure the authenticity and integrity of received messages. Trust messages can be used to transfer the needed data via XMPP for performing such an authentication. Furthermore, they can transmit the data used for distrusting a key.

2. Glossary

Endpoint
Communication endpoint owning exactly one public long-term key. In most cases that is an XMPP client instance. In the terminology of OMEMO Encryption (XEP-0384) [3], that is a device. To cover also the possibility for using multiple endpoints on the same physical device and via the same client instance, the general term endpoint is used.
Key authentication
Verification that a key received over an insecure channel is actually the one of the assumed endpoint
Key identifier
Identifier of a key (e.g., a hash value / fingerprint or the key itself)
Public key certificate
Electronic document used to prove the authenticity of a public key
Trust message
XMPP message that indicates whether specific keys are trusted or untrusted by the sending endpoint. A trust message for an endpoint's key contains the key identifier of the given key.

3. Why Trust Messages?

Trust messages can be used in conjunction with an end-to-end encryption protocol such as OpenPGP for XMPP (XEP-0373) [4] or OMEMO Encryption (XEP-0384) [3] to automatically or semi-automatically establish secure channels protected against active attacks. This protocol specifies how trust messages are transmitted and protocols such as Automatic Trust Management (ATM) (XEP-0450) [1] specify how and for which purpose they are processed.

3.1 General Advantages

Trust messages have the following advantages:

3.1.1 No Permanent Storage

A permanent storage is not needed. Cached data can be be removed as soon as the recipient made use of them. E.g., a server-side storage holding available data because it does not know when a client needs to access them, as for certificate-based approaches, is unnecessary.

3.1.2 No Additional Infrastructure

An infrastructure in additional to the one used for messages is not needed because trust messages are ordinary messages. E.g., a server-side storage and a mechanism for accessing it other than those used for messages is unnecessary.

3.2 Advantages with Encryption

The authenticity and integrity of trust messages are ensured by a signing mechanism. If trust messages are additionally encrypted, they have the following advantages:

3.2.1 Same Cryptographic Properties

The cryptographic properties of the encryption protocol are applied to the trust messages. Properties such as confidentiality, forward secrecy and deniability can have a positive impact on the authentication of keys. Hence, trust messages, in contrast to certificates, can e.g. be deniable toward a third party if the encryption protocol provides that kind of deniability.

3.2.2 Confidential Communication of Trust

The fact that an endpoint trusts a key or not can be kept confidential toward an attacker by encrypting those messages and sending them only to endpoints with authenticated keys. This means that an attacker cannot detect by the content of a trust message whether a specific key is trusted by the sender. If the trust message is sent for an authentication of a key, the involved parties of that authentication will therefore stay anonymous toward an attacker.

The encryption protects against passive attacks on the transmission of the trust messages. That way, an attacker cannot read the content of the trust messages.

The restriction to send trust messages only to endpoints with authenticated keys in addition to the encryption protects against active attacks on the transmission of the trust messages. An attacker will even after introducing a malicious key not receive a trust message encrypted with that key.

3.2.3 No Selective Blocking

Blocking data used to trust or distrust keys in transit is made more difficult. In particular, an attacker is not able to selectively block transmitted data used to distrust the attacker's key.

If an attacker cannot distinguish whether the data sent from a client is used for trusting or distrusting a key, the attacker can only randomly block some messages or the whole communication. If the communication is already compromised by an active attack, the attacker does not want to stop the whole communication. During that state, the attacker has the possibility to keep on e.g. eavesdropping or altering messages. Therefore, the attacker wants to block data that can lead to excluding the attacker. But the attacker does not want to block the communication itself.

Data that is used by the recipient to distrust the attacker's key would make it impossible for the attacker to continue to encroach on the communication. Thus, it is important to prevent an attacker from blocking data used for making trust decisions. E.g., an approach using certificates permanently stored on a server cannot prevent an attacker from specifically blocking such data because certificates have to be discoverable and identifiable as such.

It might be possible to distinguish an encrypted trust message from other encrypted messages by analyzing the network traffic over a period of time. However, the mitigation of that issue is out of scope.

4. Trust Message Structure

A trust message (i.e., the root <message/> element)

The last two points are needed to achieve their mentioned goals because a trust message does not contain a <body> element which would automatically lead to the desired result.

In the following example, two OMEMO Encryption (XEP-0384) [3] keys of Alice are indicated as trusted, one key of Bob is indicated as trusted and two other ones of Bob are indicated as untrusted.

Example 1. Trust Message Element for Alice's and Bob's OMEMO Keys used by ATM
<trust-message xmlns='urn:xmpp:tm:1' usage='urn:xmpp:atm:1' encryption='urn:xmpp:omemo:2'>
  <key-owner jid='alice@example.org'>
    <trust>aFABnX7Q/rbTgjBySYzrT2FsYCVYb49mbca5yB734KQ=</trust>
    <trust>IhpPjiKLchgrAG5cpSfTvdzPjZ5v6vTOluHEUehkgCA=</trust>
  </key-owner>
  <key-owner jid='bob@example.com'>
    <trust>YjVI04NcbTPvXLaA95RO84HPcSvyOgEZ2r5cTyUs0C8=</trust>
    <distrust>tCP1CI3pqSTVGzFYFyPYUMfMZ9Ck/msmfD0wH/VtJBM=</distrust>
    <distrust>2fhJtrgoMJxfLI3084/YkYh9paqiSiLFDVL2m0qAgX4=</distrust>
  </key-owner>
</trust-message>

5. Use Cases

Trust messages MAY be sent unencrypted to solely communicate the trust in specific keys without any other protection. But as described before, the strength of trust messages is the possibility to encrypt their content and choose to which endpoints they are sent according to the trust in the endpoints' keys.

5.1 Unencrypted Trust Message

The <trust-message/> element MUST be signed before sending for ensuring the authenticity and integrity.

5.2 Encrypted Trust Message

The <trust-message/> element SHOULD be signed and encrypted before sending for applying all advantages the encryption provides. That protects against passive attacks on the transmission of the trust message. The trust message SHOULD only be sent to endpoints whose keys have already been authenticated for also preventing active attacks on the transmission of the trust message.

Describing how the <trust-message/> element has to be used by each existing encryption protocol is out of scope. Stanza Content Encryption (XEP-0420) [2] specifies a common method for encrypting arbitrary elements which can be used by different encryption protocols. When using an encryption protocol such as OMEMO Encryption (XEP-0384) [3] that uses Stanza Content Encryption (XEP-0420) [2] (SCE), the SCE <content/> element MUST contain the <trust-message/> element as a direct child.

5.2.1 SCE Profile

A trust message SCE <envelope/> element

Example 2. SCE Envelope Element Used for a Trust Message from Alice's Endpoint to Carol
<envelope xmlns='urn:xmpp:sce:1'>
  <rpad>QHqW2arWFewoERL1a43wonBKpTmsrBWnc1d66HSDq85NgMLmjrDJV9lV</rpad>
  <time stamp='2020-01-01T00:00:00'/>
  <from jid='alice@example.org/notebook'/>
  <to jid='carol@example.com'/>
  <content>
    <trust-message xmlns='urn:xmpp:tm:1' usage='urn:xmpp:atm:1' encryption='urn:xmpp:omemo:2'>
      <key-owner jid='alice@example.org'>
        <trust>aFABnX7Q/rbTgjBySYzrT2FsYCVYb49mbca5yB734KQ=</trust>
        <trust>IhpPjiKLchgrAG5cpSfTvdzPjZ5v6vTOluHEUehkgCA=</trust>
      </key-owner>
      <key-owner jid='bob@example.com'>
        <trust>YjVI04NcbTPvXLaA95RO84HPcSvyOgEZ2r5cTyUs0C8=</trust>
        <distrust>tCP1CI3pqSTVGzFYFyPYUMfMZ9Ck/msmfD0wH/VtJBM=</distrust>
        <distrust>2fhJtrgoMJxfLI3084/YkYh9paqiSiLFDVL2m0qAgX4=</distrust>
      </key-owner>
    </trust-message>
  </content>
</envelope>

6. Implementation Notes

Message Carbons (XEP-0280) [6] minimizes the number of trust messages to be sent while having the same payload because trust messages with the same payload do not have to be sent for each endpoint. In combination with the usage of Message Archive Management (XEP-0313) [7], the delivery of trust messages to temporarily offline endpoints is ensured even if they are available under a different resource after going online than the last known one before going offline.

This specification uses Message Carbons (XEP-0280) [6] for sending a trust message to all endpoints of a contact or to all own endpoints at once. By sending a trust message to the contact, each endpoint of the contact and each own endpoint receives the same trust message by the server. Thus, a client needs to send the same trust message only once.

If not all endpoints of the contact should receive the trust message, the trust message MAY be sent to specific endpoints of the contact but for all own endpoints Message Carbons (XEP-0280) [6] MAY be used and vice versa. Even when a client does not yet have a contact, the client MAY use Message Carbons (XEP-0280) [6] for delivering a trust message to all own endpoints by sending it to the own bare JID. If then a client receives a trust message with its own full JID as the sender, it MAY discard that message directly without parsing the content.

Example: Alice's endpoint A1 authenticates the key of her endpoint A2. A1 sends the trust message for A2's key only once to all of Alice's and Bob's endpoints by using Message Carbons (XEP-0280) [6].

Attention: In that context, sending an encrypted trust message to all endpoints of a contact or to all own endpoints does not mean to encrypt it with the keys of all those endpoints. Instead, it only means that all of those endpoints should receive the trust message even if it is not encrypted for some of them and thereby not decryptable by those endpoints. Keep in mind that a trust message SHOULD only be encrypted for endpoints with authenticated keys.

7. Security Considerations

Protocols using trust messages SHOULD specify rules for processing them in order to create or sustain a secure communication. Therefore, those protocols SHOULD state in which cases from which senders trust messages are used for making trust decisions and for which keys they are sent to whom.

8. IANA Considerations

This document requires no interaction with the Internet Assigned Numbers Authority (IANA).

9. XMPP Registrar Considerations

9.1 URI Query Types

As authorized by XMPP URI Query Components (XEP-0147) [8], the XMPP Registrar maintains a registry of queries and key-value pairs for use in XMPP URIs (see <https://xmpp.org/registrar/querytypes.html>).

9.1.1 trust-message

An XMPP URI with the trust-message query type (defined as Trust Message URI) MAY be used to provide a trust message for various purposes and a single key owner out-of-band. Such a URI MAY be encoded as a QR code and used if only a QR code scan is available as a trusted channel. E.g., the initial authentication needed by Automatic Trust Management (ATM) (XEP-0450) [1] can be performed by scanning a QR code that encodes a Trust Message URI.

Only a Trust Message URI from a trusted source SHOULD be processed because of its impact on the communication's security. Therefore, users SHOULD be asked for confirmation if a Trust Message URI is used to make a trust decision.

The JID attribute of the <key-owner/> element MUST be used as the Trust Message URI's path. The first key-value pair of the URI's query MUST represent the encryption attribute of the <trust-message/> element. All remaining key-value pairs of the URI's query MUST represent the <trust/> respectively <distrust/> elements of the <key-owner/> element. Each key identifier MUST be Base16-encoded (see RFC 4648 [5]). The key of a key-value pair MUST be the element's respectively attribute's name and the value their content.

Example 3. Trust Message URI for Bob's OMEMO keys
xmpp:bob@example.com?trust-message;encryption=urn:xmpp:omemo:2;trust=623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f;distrust=b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413;distrust=d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e

9.2 Protocol Namespaces

This specification defines the following XMPP namespaces:

9.3 Protocol Versioning

If the protocol defined in this specification undergoes a revision that is not fully backwards-compatible with an older version, the XMPP Registrar shall increment the protocol version number found at the end of the XML namespaces defined herein, as described in Section 4 of XEP-0053.

10. XML Schema

<?xml version='1.0' encoding='UTF-8'?>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema'
           targetNamespace='urn:xmpp:tm:1'
           xmlns='urn:xmpp:tm:1'
           elementFormDefault='qualified'>

  <xs:element name='trust-message'>
    <xs:complexType>
      <xs:attribute name='usage' type='xs:string' use='required'/>
      <xs:attribute name='encryption' type='xs:string' use='required'/>
      <xs:sequence>
        <xs:element ref='key-owner' minOccurs='1' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

  <xs:element name='key-owner'>
    <xs:complexType>
      <xs:attribute name='jid' type='xs:string' use='required'/>
      <xs:sequence>
        <xs:element name='trust' type='xs:base64Binary' minOccurs='0' maxOccurs='unbounded'/>
        <xs:element name='distrust' type='xs:base64Binary' minOccurs='0' maxOccurs='unbounded'/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:schema>

Appendices

Appendix A: Document Information

Series
XEP
Number
0434
Publisher
XMPP Standards Foundation
Status
Experimental
Type
Standards Track
Version
0.6.0
Last Updated
2021-10-04
Approving Body
XMPP Council
Dependencies
XMPP Core, XEP-0001, XEP-0280, XEP-0334, XEP-0420
Supersedes
None
Superseded By
None
Short Name
TM
Source Control
HTML

This document in other formats: XML  PDF

Appendix B: Author Information

Melvin Keskin
Email
melvo@olomono.de
JabberID
melvo@olomono.de

Copyright

This XMPP Extension Protocol is copyright © 1999 – 2024 by the XMPP Standards Foundation (XSF).

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Visual Presentation

The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Discussion on other xmpp.org discussion lists might also be appropriate; see <https://xmpp.org/community/> for a complete list.

Errata can be sent to <editor@xmpp.org>.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. XEP-0450: Automatic Trust Management (ATM) <https://xmpp.org/extensions/xep-0450.html>.

2. XEP-0420: Stanza Content Encryption <https://xmpp.org/extensions/xep-0420.html>.

3. XEP-0384: OMEMO Encryption <https://xmpp.org/extensions/xep-0384.html>.

4. XEP-0373: OpenPGP for XMPP <https://xmpp.org/extensions/xep-0373.html>.

5. RFC 4648: The Base16, Base32, and Base64 Data Encodings <http://tools.ietf.org/html/rfc4648>.

6. XEP-0280: Message Carbons <https://xmpp.org/extensions/xep-0280.html>.

7. XEP-0313: Message Archive Management <https://xmpp.org/extensions/xep-0313.html>.

8. XEP-0147: XMPP URI Query Components <https://xmpp.org/extensions/xep-0147.html>.

Appendix H: Revision History

Note: Older versions of this specification might be available at https://xmpp.org/extensions/attic/

  1. Version 0.6.0 (2021-10-04)

    Specify key identifier encoding, improve glossary and update to XEP-0384 version 0.8.0:

    melvo
  2. Version 0.5.1 (2021-05-14)

    Update to XEP-0450 version 0.3.0 and apply consistent formatting:

    melvo
  3. Version 0.5.0 (2021-04-16)

    Update to XEP-0420 version 0.4.0 and adapt namespace to shortname:

    melvo
  4. Version 0.4.0 (2021-04-13)

    Add new section, use more precise sentences, apply consistent formatting:

    melvo
  5. Version 0.3.0 (2020-12-19)

    Clarify usage, use real namespace for examples and add missing section:

    melvo
  6. Version 0.2.0 (2020-11-05)

    Improve explanations, descriptions and examples, introduce new attribute and complete all sections:

    melvo
  7. Version 0.1.0 (2020-02-27)
    Accepted by vote of Council on 2020-02-19
    XEP Editor (jsc)
  8. Version 0.0.1 (2020-02-15)
    First draft
    melvo

Appendix I: Bib(La)TeX Entry

@report{keskin2020tm,
  title = {Trust Messages (TM)},
  author = {Keskin, Melvin},
  type = {XEP},
  number = {0434},
  version = {0.6.0},
  institution = {XMPP Standards Foundation},
  url = {https://xmpp.org/extensions/xep-0434.html},
  date = {2020-02-15/2021-10-04},
}

END