On 02/26/2013 04:28 PM, Simon McVittie wrote:
That seems a lot more XMPP-ish than "plain OTR", and addresses a concern
I've always had about OTR (that it's defined in terms of a stream of
plain-text messages, making it protocol-agnostic but unable to interact
with individual protocols' features).
However, if this is not wire-protocol-compatible with "real OTR", does
it have any particular advantages over previous XMPP work on end-to-end
TLS, with X.509 certificates that are typically self-signed and used
mainly as a vehicle for key material?
My understanding had been that the main advantage of OTR over TLS is
that it gets some "network effect" from the OTR Pidgin plugin being
somewhat widely-deployed; if that advantage isn't present, would it be
better for security to reuse widely-tested TLS libraries (OpenSSL,
GNUTLS etc.) rather than trying to get all the subtleties of crypto
right in domain-specific code?
One benefit of my protocol would be that the same "identity" (DSA key)
can be used to provide transparent OTR compatibility, since the user
could use her same credentials to speak OTR. However, I think that
something like TLS should be used instead, as long as the appropriate
features (such as deniability, and perhaps also forgeability - more on
that later) can be supported.
Which of the security properties desired by
<https://tools.ietf.org/html/draft-ietf-xmpp-e2e-requirements-01> does
this OTR-like protocol have, and does it have any more that are
desirable but not specified in that document? (For that matter, which
does OTR have?)
Since you're curious, I will give you my take on the OTR protocol in
relation to the requirements of E2E-REQ, as well as the requirements
nicely presented in your posts to the Telepathy mailing list. Please
note that I am not a cryptographer either, so I may very well be wrong
in my assertions.
Let's start by taking a look at the security requirements of E2E-REQ.
I believe that you are right in that OTR provides confidentiaility
and integrity. I would also say that OTR does support replay
protection (through the counter value) as well as perfect forward
secrecy (through continuous renegotiation of shared secrets, each
time involving a random number). Trust can be established through the
comparing the session identifier or by performing a Socialist
Millionarie's Protocol query. Authentication is done through DSA keys.
As the authenticated key exchange does not reveal the key to any
intermediate entity, it should allow for identity protection as well.
Furthermore, I guess that - since an attacker must have access to the
private DSA key, guess the secret value within a small window of time,
and, even if the attacker manages to put herself in the middle, must
be able to guess the occasional Socialist Millionaire's Protocol
query - OTR could be considered to fulfill the robustness requirement.
OTR defines a syntax for announcing which versions of the protocol are
supported, allowing for upgradability.
Summary:
+-------------------------+-----+
| Security requirement | OTR |
+-------------------------+-----+
| Confidentiality | Y |
+-------------------------+-----+
| Integrity | Y |
+-------------------------+-----+
| Reply protection | Y |
+-------------------------+-----+
| Perfect forward secrecy | Y |
+-------------------------+-----+
| Trust | Y |
+-------------------------+-----+
| Authentication | Y |
+-------------------------+-----+
| Identity protection | Y |
+-------------------------+-----+
| Robustness | Y |
+-------------------------+-----+
| Upgradability | Y |
+-------------------------+-----+
There is another set of requirements defined in E2E-REQ: Application
requirements. OTR can, as previously mentioned, only be used to
protect the content of the message <body/> element, so it does not
fulfill the generality requirement. As the implementation of OTR is
quite straight-forward, and there are some libraries available, I
would say that it's implementable. The popular use of Pidgin-OTR has
indicated that OTR is usable enough to gain widespread adoption. OTR
mentions the use of Diffie-Hellman key exchanges for shared secret
negotiation is a cheap, so I would assume that the protocol is
efficient. In order to be flexible, OTR would have to "be compatible
with a variety of existing and future cryptographic algorithms and
identity certification schemes". OTR assumes the use of DSA keys,
Diffie-Hellman key exchanges, and AES-128-CTR, so I don't think that
it qualifies. Offline messages can be decrypted later with OTR
(assuming that the shared secret is still available).
Summary:
+-------------------------+-----+
| Application requirement | OTR |
+-------------------------+-----+
| Generality | N |
+-------------------------+-----+
| Implementability | Y |
+-------------------------+-----+
| Usability | Y |
+-------------------------+-----+
| Efficiency | Y |
+-------------------------+-----+
| Flexibility | N |
+-------------------------+-----+
| Offline messages | Y |
+-------------------------+-----+
My protocol basically broadens OTR to fulfill the generality
requirement. (Being able to negotiate the prime number, it can be
argued that my protocol is somewhat more flexible, but it's still
limited to DSA, AES-128-CTR, and Diffie-Hellman.)
The below table lists the requirements mentioned by you in your
"006122" post. I agree with your assertions.
+---------------------------+-----+
| "006122" requirement | OTR |
+---------------------------+-----+
| Deniability/Repudiability | Y |
+---------------------------+-----+
| Non-repudiability | N |
+---------------------------+-----+
| Strong authentication | Y |
+---------------------------+-----+
| Weak authentication | Y |
+---------------------------+-----+
| Strong anonymity | Y |
+---------------------------+-----+
| Weak anonymity | Y |
+---------------------------+-----+
| Perfect forward secrecy | Y |
+---------------------------+-----+
I'm also a bit confused about the revealing of the MAC key in OTR. The
way I understand it, this is done to allow for forgeability (which is
stronger than repudiability/deniability); by using a malleable
encryption scheme (such as AES in CTR mode), it's apparantly made
trivial for anyone who has the MAC key to make meaningful changes to a
known transcript. I have also yet to understand how this works in the
real world. I will try to figure out the value of this requirement by
asking on the otr-devel list.
It seems to me as though many of OTR's frequently-stated advantages
(such as perfect forward secrecy and repudiability) are advantages over
older techniques like individually PGP-signing messages (XEP-0027, which
has many other flaws), but are not advantages over TLS, which shares
those properties. Is this the case?
Last time I looked at supporting OTR and/or XTLS in the Telepathy
framework, I wrote
<http://lists.freedesktop.org/archives/telepathy/2012-June/006122.html>
and
<http://lists.freedesktop.org/archives/telepathy/2012-June/006135.html>
to try to articulate what our goals for end-to-end encryption might be,
and which of those goals are satisfied by each of XTLS and OTR.
As far as I could work out in message 006135, XTLS offers just as much
deniability as OTR (anyone who can understand a message stream enough to
cite it as evidence of a conversation could also have faked the entire
conversation). Is this the case, or was I missing something important?
I don't know. It would be great if we can make something like TLS fit for
our purposes.
Thank you for your reply!
Best,
Jon Kristensen
