ATT specifies an automatic transfer of trust in public identity keys used by the end-to-end encryption protocol OMEMO.
</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-0147</spec>
<spec>XEP-0384</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>2019-03-03</date>
<initials>mk</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>
ATT is used for automatically establishing secure channels protected against active attacks between a new device and existing ones after a single mutual manual authentication between the new device and one of the existing ones.
It preserves the security level as if all devices had authenticated their keys manually.
A trusted third party is not required since a usual OMEMO message is used for transferring the information needed to authenticate a key or revoke the trust in that key.
When using &xep0384;, a public identity key is transmitted over a channel which is not protected against active attacks.
That key has to be authenticated by the receiving device over a channel which is protected against active attacks to maintain the confidentiality of sent OMEMO messages and ensuring the authenticity and integrity of received OMEMO messages.
</p>
<p>
When using OMEMO, each device has a different identity key.
That makes it possible for new devices to use end-to-end encryption protecting against passive attacks without transmitting the private key over a secure channel from an existing device to the new one.
However, the downside of this approach is that it increases the number of authentications.
A trust message for a device's key sent to another device is a trust message that contains the key identifer of the given key for authentication or revocation.
If a trust message only contains key identifiers for authentication, it is called <cite>authentication message</cite>.
The goal of key authentication is to create an end-to-end encrypted communication network exclusively of devices with authenticated keys.
As a result every communication channel between those devices is resistant against active attacks.
</p>
<p>
The network of devices which authenticated each other's keys can be seen as a complete graph with each device as a node and each mutual authentication as an edge.
The number of edges grows for each new device by the number of existing nodes.
That means to sustain a secure communication across all devices, a new key has to be authenticated by all n existing devices and vice versa.
</p>
<p>
One of those n mutual authentications requires user interaction like scanning each other's QR codes or comparing each other's key identifiers by hand.
That is the initial mutual manual authentication.
The remaining authentications can be automated relying on the secure channel established by the inital mutual manual authentication and the secure channels already created by the same procedure between the rest of the devices.
</p>
<p>
For creating the described complete graph with n nodes, a total of T(n) = (n*(n-1))/2 ∊ O(n²) mutual authentications are needed.
When using ATT, only T(n) = n-1 ∊ O(n) of them have to be made manually.
All remaining authentications can be performed automatically.
Thus, less user interaction is needed for authenticating all keys involved in the secure communication while preserving the same security level.
A trust message contains an <cite>XMPP URI</cite> (see &xep0147;) defined by the following scheme:
</p>
<examplecaption='Scheme of a Trust Message URI'><![CDATA[xmpp:<bare-jid>?omemo-trust;<auth|revoke>=<key-identifier-1>;<auth|revoke>=<key-identifier-2>;<...>;<auth|revoke>=<key-identifier-n>]]></example>
<examplecaption='Example of a Trust Message URI'><![CDATA[xmpp:user@example.org?omemo-trust;auth=623548d3835c6d33ef5cb680f7944ef381cf712bf23a0119dabe5c4f252cd02f;auth=d9f849b6b828309c5f2c8df4f38fd891887da5aaa24a22c50d52f69b4a80817e;revoke=b423f5088de9a924d51b31581723d850c7cc67d0a4fe6b267c3d301ff56d2413]]></example>
A device that receives an authentication message for a key of an own device from another own device MUST authenticate the key as soon as the key of the device that sent the authentication message is authenticated by the receiving device.
</p>
<p>
Example:
A2 authenticates A3's key by the authentication message from A1 as soon as A2 authenticated A1's key.
</p>
</section3>
</section2>
<section2topic='Revoking the Trust in a Key'anchor='usecases-revocation'>
<p>
A client MAY send a revocation message for a key that is not trusted anymore by the sending client so that key will no longer be trusted by the receiving client.
A client receiving a revocation message SHOULD revoke the trust in the corresponding key.
</p>
<p>
// TODO Further discussion has to take place before finalizing this section.
<section2topic='Storing Trust Message Information from Devices with Unauthenticated Keys'anchor='impl-storing-trust-message-information-unauthenticated-keys'>
<p>
A client MUST save the information of a trust message until the key of the device which sent the trust message is authenticated, so that the key can then be authenticated or revoked.
Afterwards the information of the trust message MAY be deleted.
</p>
<p>
Example:
When Alice's device A1 authenticates the key of Bob's device B1, A1 sends a trust message containing the keys of Alice's other device A2 to B1.
If B1 has not already authenticated A1's key, B1 stores the information provided by the trust message.
B1 authenticates A1's key and is then able to automatically authenticate A2's key.
</p>
</section2>
<section2topic='Storing Trust Message Information for Unknown Keys'anchor='impl-storing-trust-message-information-unknown-keys'>
<p>
A client MUST save the information of a trust message until it has fetched the corresponding key so that the key can then be authenticated or revoked.
Afterwards the information of the trust message can be deleted.
</p>
<p>
Example:
Alice's device A1 receives an authentication message from Bob's device B1.
That authentication message contains the key for Bob's other device B2.
If A1 has not already fetched B2's key, A1 stores the information provided by the trust message.
A1 fetches B2's key and is then able to automatically authenticate A2's key.
It is more secure to be protected against passive attacks instead of not using any encryption.
If it is not possible to authenticate a key before encrypting with it but it is desired to communicate with the key's device, it is RECOMMENDED to blindly trust new keys until the first authentication has been made.
</p>
<p>
Even ATT cannot protect the user against an attacker with a blindly trusted and undetected malicious key.
For this reason it is important to take special care of the following security aspects.
</p>
<p>
If keys are blindly trusted until the first authentication, keys which are not authenticated by then MUST NOT be used any longer for encryption until they have been authenticated too.
New keys MUST also only be used for encryption after they have been authenticated.
Without these two additional precautions it is not possible to protect the user against attackers who introduced malicious keys before or after the first authentication.