From cefba6e02ca692bfb059303af442c762a2f2c530 Mon Sep 17 00:00:00 2001 From: Sam Whited Date: Sun, 24 Apr 2016 17:44:33 -0500 Subject: [PATCH] XEP-0364: Retab --- xep-0364.xml | 547 ++++++++++++++++++++++++++------------------------- 1 file changed, 280 insertions(+), 267 deletions(-) diff --git a/xep-0364.xml b/xep-0364.xml index 3baa7ca9..6a14a99f 100644 --- a/xep-0364.xml +++ b/xep-0364.xml @@ -1,291 +1,304 @@ + %ents; ]> -
- Current Off-the-Record Messaging Usage - - This document outlines the current usage of Off-the-Record messaging in - XMPP, its drawbacks, its strengths, and recommendations for improving the - end user experience. - - &LEGALNOTICE; - 0364 - Experimental - Informational - Standards - Council - - XMPP Core - - - - NOT_YET_ASSIGNED - - Sam - Whited - sam@samwhited.com - sam@samwhited.com - - - 0.1 - 2015-08-27 - XEP Editor (mam) -

Initial published version approved by the XMPP Council.

 - - - 0.0.1 - 2015-07-28 - ssw -

Initial draft.

 - -
- -

- The Off-the-Record messaging protocol (OTR) was originally introduced in - the 2004 paper - - Off-the-Record Communication, or, Why Not To Use PGP - - - Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record - Communication, or, Why Not To Use PGP" - < - https://otr.cypherpunks.ca/otr-wpes.pdf - > - - and has since become the de facto standard for performing end-to-end - encryption in XMPP. OTR provides encryption, deniable authentication, - forward secrecy, and malleable encryption. -

-

- The OTR protocol itself is currently described by the document: - - Off-the-Record Messaging Protocol version 3 - - - "Off-the-Record Messaging Protocol version 3" - < - https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html - > - - and will not be redescribed here. Instead, this document aims to describe - OTR's usage and best practices within XMPP. It is not intended to be a - current standard, or technical specification, as better (albeit, newer and - less well tested) methods of end-to-end encryption exist for XMPP. -

- - -

- Though this document will not focus on the OTR protocol itself, a brief - overview is warranted to better understand the protocols strengths and - weaknesses. -

-

- OTR uses 128 bit AES symmetric-key encryption and the SHA-1 hash function. - An OTR session can be held only between two parties, meaning that OTR is - incompatible with &xep0045;. It provides deniability in the form of - malleable encryption (a third party may generate fake messages after the - session has ended). This means that if you were not a part of the original - conversation, you cannot prove based on captured messages alone that a - message from the conversation was actually sent by a given party. Unlike - PGP, OTR also provides forward secrecy; even if a session is recorded and - the primary key is compromised at a later date, the OTR messages will not - be able to be decrypted as each was encrypted with an ephemeral key - exchanged with Diffie-Hellman key exchange with a 1536 bit modulus. -

- - -

- Clients that support the OTR protocol do not advertise it in any of the - normal XMPP ways. Instead, OTR provides its own discovery mechanism. If a - client wishes to indicate support for OTR they include a special whitespace - tag in their messages. This tag can appear anywhere in the body of the - message stanza, but it is most often found at the end. The OTR tag - comprises the following bytes: +

+ Current Off-the-Record Messaging Usage + + This document outlines the current usage of Off-the-Record messaging in + XMPP, its drawbacks, its strengths, and recommendations for improving the + end user experience. + + &LEGALNOTICE; + 0364 + Experimental + Informational + Standards + Council + + XMPP Core + + + + NOT_YET_ASSIGNED + + Sam + Whited + sam@samwhited.com + sam@samwhited.com + + + 0.2 + 2016-04-24 + ssw + +

+ Remove RFC 2119 language other than [NOT] RECOMMENDED; add session + ending recommendations. +

+ + + + 0.1 + 2015-08-27 + XEP Editor (mam) +

Initial published version approved by the XMPP Council.

 + + + 0.0.1 + 2015-07-28 + ssw +

Initial draft.

 + +
+ +

+ The Off-the-Record messaging protocol (OTR) was originally introduced in + the 2004 paper + + Off-the-Record Communication, or, Why Not To Use PGP + + + Nikita Borisov, Ian Goldberg, Eric Brewer (2004-10-28). "Off-the-Record + Communication, or, Why Not To Use PGP" + < + https://otr.cypherpunks.ca/otr-wpes.pdf + > + + and has since become the de facto standard for performing end-to-end + encryption in XMPP. OTR provides encryption, deniable authentication, + forward secrecy, and malleable encryption. +

+

+ The OTR protocol itself is currently described by the document: + + Off-the-Record Messaging Protocol version 3 + + + "Off-the-Record Messaging Protocol version 3" + < + https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html + > + + and will not be redescribed here. Instead, this document aims to describe + OTR's usage and best practices within XMPP. It is not intended to be a + current standard, or technical specification, as better (albeit, newer and + less well tested) methods of end-to-end encryption exist for XMPP. +

+ + +

+ Though this document will not focus on the OTR protocol itself, a brief + overview is warranted to better understand the protocols strengths and + weaknesses. +

+

+ OTR uses 128 bit AES symmetric-key encryption and the SHA-1 hash function. + An OTR session can be held only between two parties, meaning that OTR is + incompatible with &xep0045; and &xep0369;. It provides deniability in the + form of malleable encryption (a third party may generate fake messages + after the session has ended). This means that if you were not a part of + the original conversation, you cannot prove, based on captured messages + alone, that a message from the conversation was actually sent by a given + party. Unlike PGP, OTR also provides forward secrecy; even if a session + is recorded and the primary key is compromised at a later date, the OTR + messages will not be able to be decrypted as each was encrypted with an + ephemeral key exchanged via Diffie-Hellman key exchange with a 1536 bit + modulus. +

+ + +

+ Clients that support the OTR protocol do not advertise it in any of the + normal XMPP ways. Instead, OTR provides its own discovery mechanism. If a + client wishes to indicate support for OTR they include a special + whitespace tag in their messages. This tag can appear anywhere in the body + of the message stanza, but it is most often found at the end. The OTR tag + comprises the following bytes: - + \x20\x09\x20\x20\x09\x09\x09\x09 \x20\x09\x20\x09\x20\x09\x20\x20 - + - and is followed by one or more of the following sequences to indicate the - version of OTR which the client supports: + and is followed by one or more of the following sequences to indicate the + version of OTR which the client supports: - + \x20\x09\x20\x09\x20\x20\x09\x20 - + - Note that this version 1 tag must come before other version tags for - compatibility; it is, however, NOT RECOMMENDED to implement version 1 of - the OTR protocol. + Note that this version 1 tag must come before other version tags for + compatibility; it is, however, NOT RECOMMENDED to implement version 1 of + the OTR protocol. - + \x20\x20\x09\x09\x20\x20\x09\x20 - + - + \x20\x20\x09\x09\x20\x20\x09\x09 - -

-

- When a client sees this special string in the body of a message stanza it - may choose to start an OTR session immediately, or merely indicate support - to the user and allow the user to manually start a session. This is done by - sending a message stanza containing an OTR query message in the body which - indicates the supported versions of OTR. In XMPP these are most commonly - version 2 and version 3, which would be indicated by a message stanza which - has a body that starts with the string: + +

+

+ When a client sees this special string in the body of a message stanza it + may choose to start an OTR session immediately, or merely indicate support + to the user and allow the user to manually start a session. This is done + by sending a message stanza containing an OTR query message in the body + which indicates the supported versions of OTR. In XMPP these are most + commonly version 2 and version 3, which would be indicated by a message + stanza which has a body that starts with the string: - + ?OTR?v23? - -

-

- Any message which begins with the afforementioned string (note that the - version number[s] may be different), postfixed with a payload should be - decrypted as an OTR message. The initialization message should not contain - a payload, and should just be the initialization string by itself. -

- - - -

- Some clients in the wild have been known to insert XML in the - <body> node of a message. Clients that support OTR should tolerate - encrypted payloads which expand to unescaped XML, and treat it as plain - text. -

- - -

- XMPP is designed so that the client needs to know very little about where - and how a message will be routed. Generally, clients are encouraged to - send messages to the bare JID and allow the server to route the messages - as it sees fit. However, OTR requires that messages be sent to a - particular resource. Therefore clients SHOULD send OTR messages to a full - JID, possibly allowing the user to determine which resource they wish to - start an encrypted session with. Furthermore, if a client receives a - request to start an OTR session in a carboned message (due to a server - which does not support the aforementioned "private" directive, or a - client which does not set it), it SHOULD be silently ignored. -

- - -

- &xep0334; defines a set of hints for how messages should be handled by - XMPP servers. These hints are not hard and fast rules, but suggestions - which the servers may or may not choose to follow. Best practice is to - include the following hints on all OTR messages: + +

+

+ Any message which begins with the afforementioned string (note that the + version number[s] may be different), postfixed with a payload should be + decrypted as an OTR message. The initialization message should not contain + a payload, and should just be the initialization string by itself. +

+ + + +

+ Some clients in the wild have been known to insert XML in the + <body> node of a message. Clients that support OTR should tolerate + encrypted payloads which expand to unescaped XML, and treat it as plain + text. +

+ + +

+ XMPP is designed so that the client needs to know very little about + where and how a message will be routed. Generally, clients are + encouraged to send messages to the bare JID and allow the server to + route the messages as it sees fit. However, OTR requires that messages + be sent to a particular resource. Therefore clients should send OTR + messages to a full JID, possibly allowing the user to determine which + resource they wish to start an encrypted session with. Furthermore, if a + client receives a request to start an OTR session in a carboned message + (due to a server which does not support the aforementioned "private" + directive, or a client which does not set it), it should be silently + ignored. +

+ + +

+ &xep0334; defines a set of hints for how messages should be handled by + XMPP servers. These hints are not hard and fast rules, but suggestions + which the servers may or may not choose to follow. Best practice is to + include the following hints on all OTR messages: - - - ]]> -

- -

- Similarly the "private" directive from &xep0280; should also be included - to indicate that carbons are not necessary (since no other resource will - be able to read the message): + + + ]]> +

- - ]]> - - All together, an example OTR message might look like this (with the - majority of the body stripped out for readability): +

+ Similarly the "private" directive from &xep0280; should also be included + to indicate that carbons are not necessary (since no other resource will + be able to read the message): - - ?OTR?v23?... - - - - - ]]> -

- - - -

- &rfc5122; defines a Uniform Resource Identifier (URI) and Internationalized - Resource Identifier (IRI) scheme for XMPP entities, and &xep0147; defines - various query components for use with XMPP URI's. When an entity has an - associated OTR fingerprint it's URI is often formed with "otr-fingerprint" - in the query string. Eg. + + ]]> - + All together, an example OTR message might look like this (with the + majority of the body stripped out for readability): + + + ?OTR?v23?... + + + + + ]]> +

+ + + +

+ &rfc5122; defines a Uniform Resource Identifier (URI) and + Internationalized Resource Identifier (IRI) scheme for XMPP entities, and + &xep0147; defines various query components for use with XMPP URI's. When + an entity has an associated OTR fingerprint it's URI is often formed with + "otr-fingerprint" in the query string. Eg. + + xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338 - -

-

- The ®ISTRAR; maintains a registry of queries and key-value pairs for use - in XMPP URIs at &QUERYTYPES;. As of the date this document was authored, - the 'otr-fingerprint' query string has not been formally defined and has - therefore is not officially recognized by the registrar. -

- - -

- Thanks to Daniel Gultsch for his excellent - - article - - - Daniel Gultsch (Retreived on 2015-07-29). "Observations on Imlementing - XMPP" - < - https://github.com/siacs/Conversations/blob/development/docs/observations.md - > - - on the pitfalls of implementing OTR, and to Georg Lukas for his feedback. -

- - -

- While this document describes an existing protocol which is streamed over - XMPP and therefore does not introduce any new security concerns itself, it - is worth mentioning a few security issues with the underlying OTR protocol: -

-

- Because Diffie-Hellman (D-H) key exchange is unauthenticated, the initial - D-H exchange which sets up the encrypted channel is vulnerable to a - man-in-the-middle attack. No sensitive information should be sent over the - encrypted channel until mutual authentication has been performed - inside the encrypted channel. -

-

- OTR makes use of the SHA-1 hash algorithm. While no practical attacks have - been observed in SHA-1 at the time of this writing, theoretical attacks - have been constructed, and attacks have been performed on hash functions - that are similar to SHA-1. One cryptographer estimated that the cost - of generating SHA-1 collisions was $2.77 million dollars in 2012, and would - drop to $700,000 by 2015. - - Bruce Schneier (2012-10-05). "When Will We See Collisions for SHA-1?" - < - https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html - > - . - This puts generating SHA-1 collisions well within the reach of governments, - malicious organizations, and even well-funded individuals. -

- - -

- This document requires no interaction with the Internet Assigned Numbers - Authority (IANA). -

- - -

- No namespaces or parameters need to be registered with the XMPP Registrar - as a result of this document. -

- + +

+

+ The ®ISTRAR; maintains a registry of queries and key-value pairs for + use in XMPP URIs at &QUERYTYPES;. As of the date this document was + authored, the 'otr-fingerprint' query string has not been formally defined + and has therefore is not officially recognized by the registrar. +

+ + +

+ Thanks to Daniel Gultsch for his excellent + + article + + + Daniel Gultsch (Retreived on 2015-07-29). "Observations on Imlementing + XMPP" + < + https://github.com/siacs/Conversations/blob/development/docs/observations.md + > + + on the pitfalls of implementing OTR, and to Georg Lukas for his feedback. +

+ + +

+ While this document describes an existing protocol which is streamed over + XMPP and therefore does not introduce any new security concerns itself, it + is worth mentioning a few security issues with the underlying OTR + protocol: +

+

+ Because Diffie-Hellman (D-H) key exchange is unauthenticated, the initial + D-H exchange which sets up the encrypted channel is vulnerable to a + man-in-the-middle attack. No sensitive information should be sent over the + encrypted channel until mutual authentication has been performed inside + the encrypted channel. +

+

+ OTR makes use of the SHA-1 hash algorithm. While no practical attacks have + been observed in SHA-1 at the time of this writing, theoretical attacks + have been constructed, and attacks have been performed on hash functions + that are similar to SHA-1. One cryptographer estimated that the cost of + generating SHA-1 collisions was $2.77 million dollars in 2012, and would + drop to $700,000 by 2015. + + Bruce Schneier (2012-10-05). "When Will We See Collisions for SHA-1?" + < + https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html + > + . + This puts generating SHA-1 collisions well within the reach of + governments, malicious organizations, and even well-funded individuals. +

+ + +

+ This document requires no interaction with the Internet Assigned Numbers + Authority (IANA). +

+ + +

+ No namespaces or parameters need to be registered with the XMPP Registrar + as a result of this document. +

+