moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

XEP-0364: Retab

This commit is contained in:
Sam Whited 2016-04-24 17:44:33 -05:00
parent 70561049c7
commit cefba6e02c
1 changed files with 280 additions and 267 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

103
xep-0364.xml
View File

@ -30,6 +30,17 @@
<email>sam@samwhited.com</email>
<jid>sam@samwhited.com</jid>
</author>
<revision>
<version>0.2</version>
<date>2016-04-24</date>
<initials>ssw</initials>
<remark>
<p>
Remove RFC 2119 language other than [NOT] RECOMMENDED; add session
ending recommendations.
</p>
</remark>
</revision>
<revision>
<version>0.1</version>
<date>2015-08-27</date>
@ -87,24 +98,25 @@
<p>
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.
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.
</p>
</section1>
<section1 topic='Discovery'>
<p>
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
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:
<example caption='OTR tag'>
@ -133,11 +145,11 @@
<p>
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:
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:
<example caption='OTR query'>
?OTR?v23?
@ -161,16 +173,17 @@
</section2>
<section2 topic='Routing'>
<p>
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.
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.
</p>
</section2>
<section2 topic='Processing Hints'>
@ -199,8 +212,7 @@
majority of the body stripped out for readability):
<example caption='OTR message with processing hints'><![CDATA[
<message
from='malvolio@stewardsguild.lit/countesshousehold'
<message from='malvolio@stewardsguild.lit/countesshousehold'
to='olivia@countess.lit/veiled'>
<body>?OTR?v23?...</body>
<no-copy xmlns="urn:xmpp:hints"/>
@ -213,21 +225,21 @@
</section1>
<section1 topic='Use in XMPP URIs'>
<p>
&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.
&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.
<example caption='OTR Fingerprint'>
xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
</example>
</p>
<p>
The &REGISTRAR; 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.
The &REGISTRAR; 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.
</p>
</section1>
<section1 topic='Acknowledgements' anchor='acks'>
@ -250,21 +262,22 @@ xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
<p>
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:
is worth mentioning a few security issues with the underlying OTR
protocol:
</p>
<p>
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.
encrypted channel until mutual authentication has been performed inside
the encrypted channel.
</p>
<p>
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
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.
<note>
Bruce Schneier (2012-10-05). "When Will We See Collisions for SHA-1?"
@ -272,8 +285,8 @@ xmpp:feste@allfools.lit?otr-fingerprint=AEA4D503298797D4A4FC823BC1D24524B4C54338
https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html
</link>&gt;
</note>.
This puts generating SHA-1 collisions well within the reach of governments,
malicious organizations, and even well-funded individuals.
This puts generating SHA-1 collisions well within the reach of
governments, malicious organizations, and even well-funded individuals.
</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>