moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 08:45:04 -05:00
Code Issues Releases Wiki Activity

Accept inbox/trust-messages.xml as XEP-0434

Browse Source
This commit is contained in:
Jonas Schäfer 2020-02-27 17:54:43 +01:00
parent 487dc30f4e
commit e1553c754b
1 changed files with 247 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

247
xep-0434.xml Normal file
View File

@ -0,0 +1,247 @@
<?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 &lt;<link url='https://xmpp.org/extensions/xep-0380.html#table-1'>https://xmpp.org/extensions/xep-0380.html#table-1</link>&gt;.</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>0434</number>
<status>Experimental</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.1.0</version>
<date>2020-02-27</date>
<initials>XEP Editor (jsc)</initials>
<remark>Accepted by vote of Council on 2020-02-19.</remark>
</revision>
<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&apos;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&apos;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>