From 848938394c69e6ca884baa490cc8ea7ea758d477 Mon Sep 17 00:00:00 2001 From: Melvin Keskin Date: Sat, 15 Feb 2020 18:52:43 +0100 Subject: [PATCH] ProtoXEP: Trust Messages --- inbox/trust-messages.xml | 241 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 241 insertions(+) create mode 100644 inbox/trust-messages.xml diff --git a/inbox/trust-messages.xml b/inbox/trust-messages.xml new file mode 100644 index 00000000..091bc50c --- /dev/null +++ b/inbox/trust-messages.xml @@ -0,0 +1,241 @@ + + + encryption protocolsExplicit Message Encryption - Encryption Protocols <https://xmpp.org/extensions/xep-0380.html#table-1>."> +%ents; +]> + + +
+ Trust Messages + + 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. + + &LEGALNOTICE; + xxxx + ProtoXEP + Standards Track + Standards + Council + + XMPP Core + XEP-0001 + XEP-0280 + XEP-0334 + XEP-0420 + + + + NOT_YET_ASSIGNED + + Melvin + Keskin + melvo@olomono.de + melvo@olomono.de + + + 0.0.1 + 2020-02-15 + mk +

First draft.

 + +
+ +

+ 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 a new malicious endpoint with an own key, 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 which 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 a channel which is protected against active attacks to maintain the confidentiality of sent messages and ensure the authenticity and integrity of received messages. +

+

+ A trust message is an XMPP message that contains the information of whether the sending endpoint trusts a specific public long-term key. + The authenticity and integrity of the message is ensured by a signing mechanism. + Trust messages can be used in conjunction with an end-to-end encryption protocol like &xep0373; or &xep0384; e.g. to automatically or semi-automatically establish secure channels protected against active attacks. +

+

+ Furthermore, 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. + That means particularly that an attacker cannot detect by the content of a trust message whether an authentication of a key took place. + An authentication will therefore stay anonymous toward an attacker. + The encryption protects against passive attacks since an attacker cannot read the content of the trust message. + The restriction to send trust messages only to endpoints with authenticated keys in addition to the encryption protects against active attacks since the attacker will not, after introducing a malicious key, receive a trust message encrypted with that key. +

+ + +
+ +
Endpoint
+
+ Communication endpoint owning exactly one public long-term key. + In most cases that is an XMPP client instance. + In the terminology of &xep0384;, 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 fingerprint or the key itself)
+ + +
Trust message
+
+ XMPP message which indicates that specific keys are trusted or not trusted by the sender. + A trust message for an endpoint's key contains the key identifier of the given key. +
+ +
+ + +

+ A trust message MUST be signed in a way to ensure its authenticity and integrity. +

+

+ The part specific for a trust message begins with the ]]> element. + Its encryption attribute MUST specify the encryption protocol that uses the keys denoted by their identifiers. + To send a trust message for keys of &xep0373; the attribute or for keys of &xep0384; the attribute MUST be used. + For other values there is an overview of possible &encryption-protocols;. + A trust message MUST contain at least one ]]> element and each element MUST contain at least one ]]> or ]]> element. + Inside of each ]]> or ]]> element there MUST be exactly one key identifier. + Those elements are used for the following purposes: +

+

+ In the following example the keys of the later given identifiers are used by the encryption protocol &xep0384; specified by eu.siacs.conversations.axolotl. +

+ ]]> +

+ In the following example the keys of the later given identifiers belong to alice@example.org. +

+ ]]> +

+ In the following example the key corresponding to the identifier inside ]]> and ]]> is trusted by the sending endpoint. +

+ 6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4]]> +

+ In the following example the key corresponding to the identifier inside the ]]> and ]]> is not trusted by the sending endpoint. +

+ b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413]]> + + +

+ An endpoint of alice@example.org MAY send a trust message to other endpoints of alice@example.org, to contacts like bob@example.com or to a specific resource like carol@example.net/phone. +

+

+ The usage of &xep0280; for trust messages is RECOMMENDED. + It 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 &xep0313;, 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. + Additionally, using &xep0280; for every encrypted trust message will lead to send trust messages which are less distinguishable by analyzing their content from other encrypted messages using &xep0420;. + However, it may be possible to distinguish an encrypted trust message from other encrypted messages and therefore detect the fact that a specific authentication took place by analyzing the network traffic over a period of time but that is out of scope for this specification. +

+

TODO: Move this paragraph to &xep0420;. + The following message attribute and element are RECOMMENDED because without having ]]>, the goals of them would not be achieved. + is needed to deliver the trust message to all endpoints (see XEP-0280: Message Carbons). + ]]> is needed to deliver the trust message to each offline endpoint after it went online (see XEP-0313: Message Archive Management and XEP-0334: Message Processing Hints). +

+

+ In the following examples Alice's endpoint sends a trust message for &xep0384; (eu.siacs.conversations.axolotl) keys of own endpoints and Bob's endpoints to Carol's resource "phone". + Alice's keys corresponding to the identifiers starting with "68" and "22" are trusted by Alice's endpoint connected via resource "laptop". + Bob's key corresponding to the identifiers starting with "68" and "22" are trusted by Alice's endpoint connected via resource "laptop". + Bob's key corresponding to the identifier starting with "62" is trusted by Alice's endpoint connected via resource "laptop" but not Bob's keys corresponding to the identifiers starting with "b4" and "d9". +

+ +

+ A trust message before encryption or without any encryption could look like the following example. + Keep in mind, like said before, that the authenticity and integrity of the message MUST be ensured by a signing mechanism even if the message is not encrypted. + However, the strength of trust messages is the possibility to encrypt them and to choose its recipients. +

+ + + + + 6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4 + 221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020 + + + 623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f + b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413 + d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e + + + +]]> + + +

+ Like described in the introduction, it is possible to encrypt a trust message and send it only to endpoints whose keys have already been authenticated. + Both actions are RECOMMENDED, especially for concealing the fact that an endpoint authenticated another endpoint's key. + When using an end-to-end encryption like &xep0384; which cannot encrypt arbitrary elements, &xep0420; is needed to encrypt a trust message. + The following example shows how such a message could look like. + For encrypting with &xep0373;, the element ]]> MUST be replaced by ]]>, the element ]]> by ]]> and ...]]> MUST be removed. +

+ + + +
+ ... +
+ + QHqW2arWFewoERL1a43wonBKpTmsrBWnc1d66HSDq85NgMLmjrDJV9lV + + + +]]> + + + +

+ This specification uses &xep0280; 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 &xep0280; MAY be used and vice versa. + Even when a client does not yet have a contact, the client MAY use &xep0280; 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 &xep0280;. +

+

+ 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. +

+ + +

REQUIRED.

+ + +

REQUIRED.

+ + +

REQUIRED for protocol specifications.

+ +