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.
</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 another channel which is already protected against active attacks to maintain the confidentiality of sent messages and ensure the authenticity and integrity of received messages.
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.
</p>
@ -128,7 +141,7 @@
@@ -128,7 +141,7 @@
<di>
<dt>Trust message</dt>
<dd>
XMPP message which indicates that specific keys are trusted or untrusted by the sending endpoint.
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.
</dd>
</di>
@ -193,11 +206,11 @@
@@ -193,11 +206,11 @@
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 which can lead to excluding the attacker.
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.
</p>
<p>
Data which 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.
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.
</p>
@ -214,7 +227,7 @@
@@ -214,7 +227,7 @@
</p>
<ul>
<li>
MUST contain exactly one <![CDATA[<trust-message/>]]> direct child element which
MUST contain exactly one <![CDATA[<trust-message/>]]> direct child element that
<ul>
<li>
MUST be signed in a way to ensure its authenticity and integrity.
@ -226,19 +239,19 @@
@@ -226,19 +239,19 @@
MUST have an <em>xmlns</em> attribute specifying its namespace <em>&ns;</em>.
</li>
<li>
MUST have a <em>usage</em> attribute specifying the namespace of the protocol which uses the trust message for a specific purpose.
MUST have a <em>usage</em> attribute specifying the namespace of the protocol that uses the trust message for a specific purpose.
</li>
<li>
MUST have an <em>encryption</em> attribute specifying the namespace of the encryption protocol for which the keys are used.
</li>
<li>
MUST contain at least one <![CDATA[<key-owner/>]]> direct child element which
MUST contain at least one <![CDATA[<key-owner/>]]> direct child element that
<ul>
<li>
MUST have a <em>JID</em> attribute specifying the owner of the keys.
MUST have a <em>JID</em> attribute specifying the bare JID of the key owner.
</li>
<li>
MUST contain at least one <![CDATA[<trust/>]]> or <![CDATA[<distrust/>]]> direct child element which indicates the trust respectively distrust in a key.
MUST contain at least one <![CDATA[<trust/>]]> or <![CDATA[<distrust/>]]> direct child element indicating the trust respectively distrust in a key.
Each <![CDATA[<trust/>]]> and <![CDATA[<distrust/>]]> element MUST contain exactly one key identifier.
</li>
</ul>
@ -291,7 +304,7 @@
@@ -291,7 +304,7 @@
<p>
Describing how the <![CDATA[<trust-message/>]]> element has to be used by each existing encryption protocol is out of scope.
&xep0420; specifies a common method for encrypting arbitrary elements which can be used by different encryption protocols.
When using an encryption protocol such as &xep0384;which uses &xep0420; (SCE), the SCE <![CDATA[<payload/>]]> element MUST contain the <![CDATA[<trust-message/>]]> element as a direct child.
When using an encryption protocol such as &xep0384;that uses &xep0420; (SCE), the SCE <![CDATA[<payload/>]]> element MUST contain the <![CDATA[<trust-message/>]]> element as a direct child.
An XMPP URI with the <em>trust-message</em> query type (defined as <em>Trust Message URI</em>) 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 <em>initial authentication</em> needed by &xep0450; can be performed by scanning a QR code that encodes a Trust Message URI.
</p>
<p>
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.
</p>
<p>
The <em>JID</em> attribute of the <![CDATA[<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 <em>encryption</em> attribute of the <![CDATA[<trust-message/>]]> element.
All remaining key-value pairs of the URI's query MUST represent the <![CDATA[<trust/>]]> respectively <![CDATA[<distrust/>]]> elements of the <![CDATA[<key-owner/>]]> element.
The key of a key-value pair MUST be the element's respectively attribute's name and the value their content.
</p>
<examplecaption='Trust Message URI for Bob's OMEMO keys'><
Jonas Schäfer
2 years ago