mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-26 19:22:15 -05:00
242 lines
15 KiB
XML
242 lines
15 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM 'xep.ent'>
|
|
<!ENTITY encryption-protocols "<span class='ref'><link url='https://xmpp.org/extensions/xep-0380.html#table-1'>encryption protocols</link></span><note>Explicit Message Encryption - Encryption Protocols <<link url='https://xmpp.org/extensions/xep-0380.html#table-1'>https://xmpp.org/extensions/xep-0380.html#table-1</link>>.</note>">
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Trust Messages</title>
|
|
<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.
|
|
</abstract>
|
|
&LEGALNOTICE;
|
|
<number>xxxx</number>
|
|
<status>ProtoXEP</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<approver>Council</approver>
|
|
<dependencies>
|
|
<spec>XMPP Core</spec>
|
|
<spec>XEP-0001</spec>
|
|
<spec>XEP-0280</spec>
|
|
<spec>XEP-0334</spec>
|
|
<spec>XEP-0420</spec>
|
|
</dependencies>
|
|
<supersedes/>
|
|
<supersededby/>
|
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
|
<author>
|
|
<firstname>Melvin</firstname>
|
|
<surname>Keskin</surname>
|
|
<email>melvo@olomono.de</email>
|
|
<jid>melvo@olomono.de</jid>
|
|
</author>
|
|
<revision>
|
|
<version>0.0.1</version>
|
|
<date>2020-02-15</date>
|
|
<initials>mk</initials>
|
|
<remark><p>First draft.</p></remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction' anchor='intro'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='Glossary' anchor='glossary'>
|
|
<dl>
|
|
<di>
|
|
<dt>Endpoint</dt>
|
|
<dd>
|
|
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.
|
|
</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Key authentication</dt>
|
|
<dd>Verification that a key received over an insecure channel is actually the one of the assumed endpoint</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Key identifier</dt>
|
|
<dd>Identifier of a key (e.g., a fingerprint or the key itself)</dd>
|
|
</di>
|
|
<di>
|
|
<dt>Trust message</dt>
|
|
<dd>
|
|
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.
|
|
</dd>
|
|
</di>
|
|
</dl>
|
|
</section1>
|
|
<section1 topic='Trust Message Structure' anchor='trust-message-structure'>
|
|
<p>
|
|
A trust message MUST be signed in a way to ensure its authenticity and integrity.
|
|
</p>
|
|
<p>
|
|
The part specific for a trust message begins with the <![CDATA[<trust-message>]]> 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 <![CDATA[encryption='urn:xmpp:openpgp:0']]> or for keys of &xep0384; the attribute <![CDATA[encryption='eu.siacs.conversations.axolotl']]> MUST be used.
|
|
For other values there is an overview of possible &encryption-protocols;.
|
|
A trust message MUST contain at least one <![CDATA[<key-owner>]]> element and each element MUST contain at least one <![CDATA[<trust>]]> or <![CDATA[<distrust>]]> element.
|
|
Inside of each <![CDATA[<trust>]]> or <![CDATA[<distrust>]]> element there MUST be exactly one key identifier.
|
|
Those elements are used for the following purposes:
|
|
</p>
|
|
<p>
|
|
In the following example the keys of the later given identifiers are used by the encryption protocol &xep0384; specified by eu.siacs.conversations.axolotl.
|
|
</p>
|
|
<example caption='Specifying the Encryption Protocol of the Keys'><![CDATA[<trust-message xmlns='urn:xmpp:trust-messages:0' encryption='eu.siacs.conversations.axolotl'>]]></example>
|
|
<p>
|
|
In the following example the keys of the later given identifiers belong to alice@example.org.
|
|
</p>
|
|
<example caption='Specifying the JID Owning the Keys'><![CDATA[<key-owner jid='alice@example.org'>]]></example>
|
|
<p>
|
|
In the following example the key corresponding to the identifier inside <![CDATA[<trust>]]> and <![CDATA[</trust>]]> is trusted by the sending endpoint.
|
|
</p>
|
|
<example caption='Indicating the Trust in a Specific Key'><![CDATA[<trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>]]></example>
|
|
<p>
|
|
In the following example the key corresponding to the identifier inside the <![CDATA[<distrust>]]> and <![CDATA[</distrust>]]> is not trusted by the sending endpoint.
|
|
</p>
|
|
<example caption='Indicating the Distrust in a Specific Key'><![CDATA[<distrust>b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413</distrust>]]></example>
|
|
</section1>
|
|
<section1 topic='Use Cases' anchor='usecases'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p> TODO: Move this paragraph to &xep0420;.
|
|
The following message attribute and element are RECOMMENDED because without having <![CDATA[<body>]]>, the goals of them would not be achieved.
|
|
<![CDATA[type='chat']]> is needed to deliver the trust message to all endpoints (see <link url='https://xmpp.org/extensions/xep-0280.html#recommended-rules'>XEP-0280: Message Carbons</link>).
|
|
<![CDATA[<store xmlns='urn:xmpp:hints'/>]]> is needed to deliver the trust message to each offline endpoint after it went online (see <link url='https://xmpp.org/extensions/xep-0313.html#business-storeret-user-archives'>XEP-0313: Message Archive Management</link> and <link url='https://xmpp.org/extensions/xep-0334.html#sect-idm45856619663120'>XEP-0334: Message Processing Hints</link>).
|
|
</p>
|
|
<p>
|
|
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".
|
|
</p>
|
|
<section2 topic='Unencrypted Trust Message' anchor='usecase-unencrypted-trust-message'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<example caption='Alice's endpoint sends an unencrypted trust message to Carol'><![CDATA[
|
|
<message from='alice@example.org/laptop' to='carol@example.org' type='chat'>
|
|
<store xmlns='urn:xmpp:hints'/>
|
|
<trust-message xmlns='urn:xmpp:trust-messages:0' encryption='eu.siacs.conversations.axolotl'>
|
|
<key-owner jid='alice@example.org'>
|
|
<trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>
|
|
<trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
|
|
</key-owner>
|
|
<key-owner jid='bob@example.com'>
|
|
<trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
|
|
<distrust>b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413</distrust>
|
|
<distrust>d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e</distrust>
|
|
</key-owner>
|
|
</trust-message>
|
|
</message>
|
|
]]></example>
|
|
</section2>
|
|
<section2 topic='Encrypted Trust Message' anchor='usecase-encrypted-trust-message'>
|
|
<p>
|
|
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 <![CDATA[<encrypted xmlns='eu.siacs.conversations.axolotl'>]]> MUST be replaced by <![CDATA[<openpgp xmlns='urn:xmpp:openpgp:0'>]]>, the element <![CDATA[<envelope xmlns='urn:xmpp:sce:0'>]]> by <![CDATA[<signcrypt xmlns='urn:xmpp:openpgp:0'>]]> and <![CDATA[<header sid='27183'>...</header>]]> MUST be removed.
|
|
</p>
|
|
<example caption='Alice's endpoint sends an encrypted trust message to Carol'><![CDATA[
|
|
<message from='alice@example.org/laptop' to='carol@example.org' type='chat'>
|
|
<store xmlns='urn:xmpp:hints'/>
|
|
<encrypted xmlns='eu.siacs.conversations.axolotl'>
|
|
<header sid='17183'>
|
|
...
|
|
</header>
|
|
<envelope xmlns='urn:xmpp:sce:0'>
|
|
<rpad>QHqW2arWFewoERL1a43wonBKpTmsrBWnc1d66HSDq85NgMLmjrDJV9lV</rpad>
|
|
<time stamp='2020-01-01T00:00:00'/>
|
|
<from jid='alice@example.org/laptop'/>
|
|
<to jid='carol@example.org'/>
|
|
<payload>
|
|
<trust-message xmlns='urn:xmpp:trust-messages:0' encryption='eu.siacs.conversations.axolotl'>
|
|
<key-owner jid='alice@example.org'>
|
|
<trust>6850019d7ed0feb6d3823072498ceb4f616c6025586f8f666dc6b9c81ef7e0a4</trust>
|
|
<trust>221a4f8e228b72182b006e5ca527d3bddccf8d9e6feaf4ce96e1c451e8648020</trust>
|
|
</key-owner>
|
|
<key-owner jid='bob@example.com'>
|
|
<trust>623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f</trust>
|
|
<distrust>b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413</distrust>
|
|
<distrust>d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e</distrust>
|
|
</key-owner>
|
|
</trust-message>
|
|
</payload>
|
|
</envelope>
|
|
</encrypted>
|
|
</message>
|
|
]]></example>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Implementation Notes' anchor='impl'>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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;.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</section1>
|
|
<section1 topic='IANA Considerations' anchor='iana'>
|
|
<p>REQUIRED.</p>
|
|
</section1>
|
|
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
|
<p>REQUIRED.</p>
|
|
</section1>
|
|
<section1 topic='XML Schema' anchor='schema'>
|
|
<p>REQUIRED for protocol specifications.</p>
|
|
</section1>
|
|
</xep>
|