Subject: [xmpp] Self Introduction

From: Jon Kristensen <[email-masked]>
Date: Tue, 26 Feb 2013 15:35:30 +0100

Hello, everyone!

I would like to briefly introduce myself to the members of this mailing 
list, and to inform you of my interest of contributing to the 
standardization of the use of the Off-the-Record protocol with XMPP.

My relevant past experience includes being one of the co-authors of 
Pontarius XMPP[1], a client XMPP library for Haskell, as well as the 
prototyping of a OTR-based (but (so far) OTR-incompatible) JavaScript 
application currently called Yabasta[2].

In the process of prototyping Yabasta, I have "designed" an OTR-like 
protocol[3] that, while based on OTR, differs from OTR in a number of 
ways. Most importantly, the OTR messages (be it the authenticated key 
exchange, the protected payloads, or the Socialist Millionaire's 
Protocol) are expressed with XML instead of with a binary encoding. 
Also, the prime numbers used are negotiatable, and any XML payloads can 
be protected (not just message bodies). (I never meant to go "Not 
invented here" in regards to OTR: my intention was simply to make the 
protocol easier to understand and to implement, more flexible, and 
better suitable for XMPP. However, I have since then that straying so 
far from OTR might not have been the best idea.)

Please don't hesitate to contact me if you are working on anything 
related to the above, or if you have any other questions or concerns.

Warm regards,
Jon Kristensen

[1]: http://hackage.haskell.org/package/pontarius-xmpp/
[2]: https://yabasta.com/
[3]: https://github.com/jonkri/yabasta-protocol/

---

From: Richard Barnes <[email-masked]>
Date: Wed, 27 Feb 2013 13:30:18 -0500

Any comments on draft-miller-xmpp-e2e?
<http://tools.ietf.org/html/draft-miller-xmpp-e2e>

On Tue, Feb 26, 2013 at 9:35 AM, Jon Kristensen <[email-masked]> wrote:

> protocol[3] that, while based on OTR, differs from OTR in a number of ways.
> Most importantly, the OTR messages (be it the authenticated key exchange,
> the protected payloads, or the Socialist Millionaire's Protocol) are
> expressed with XML instead of with a binary encoding. Also, the prime
> numbers used are negotiatable, and any XML payloads can be protected (not
> just message bodies). (I never meant to go "Not invented here" in regards
> to OTR: my intention was simply to make the protocol easier to understand
> and to implement, more flexible, and better suitable for XMPP. However, I
> have since then that straying so far from OTR might not have been the best
> idea.)
>
> Please don't hesitate to contact me if you are working on anything related
> to the above, or if you have any other questions or concerns.
>
> Warm regards,
> Jon Kristensen
>
> [1]: http://hackage.haskell.org/**package/pontarius-xmpp/<http://hackage.haskell.org/package/pontarius-xmpp/>
> [3]: https://github.com/jonkri/**yabasta-protocol/<https://github.com/jonkri/yabasta-protocol/>
> ______________________________**_________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/xmpp<https://www.ietf.org/mailman/listinfo/xmpp>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 27 Feb 2013 11:34:13 -0700

On 2/26/13 7:35 AM, Jon Kristensen wrote:
> Hello, everyone!
> 
> I would like to briefly introduce myself to the members of this
> mailing list, and to inform you of my interest of contributing to
> the standardization of the use of the Off-the-Record protocol with
> XMPP.

Paul Wouters and I plan to work together IRL at the IETF meeting in
Orlando on an informational specification for OTRv3 (the current
version). Any future version that is more XMPP-friendly would happen
in parallel with (or after) that documentation effort.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 27 Feb 2013 19:11:22 +0000

[ "switching" venue for wider security review ]
[ context for XMPP WG: http://mail.jabber.org/pipermail/standards/2013-February/027167.html ]

Hello Jon,

I find this work interesting, but I also have some concerns here.  I don't expect definitive answers to all of them, but think they're worth discussion to help the working group choose a path forward.

I think there is an additional application requirement concern regarding multiple resources.  The XSF has technologies in development to multiplex chat conversations, namely [CARBONS].  I'm not sure that E2E-REQ calls it out, but it will be an important consideration for the very near term.  I'm curious how yabasta can accommodate things like carbons without in a user-transparent manner.

from your response on [email-masked], an effective fork of OTR doesn't exactly meet the (existing) XMPP WG charter requirement.  I'm not saying that's necessarily bad, but it is something to consider as we move forward.  Not that I have much moral authority here with [XMPP-E2E] (-;  However, my draft is based on a technology with a lot of momentum behind it, so it is likely to be "widely deployed and implemented" by the time we get completely done.

One of the big detractions from RFC3923 was the multiple paths followed.  It looks like this duplicates that, and not in a necessarily better route.  Various other attempts at this space have tried to deal with a single path (whole stanzas) to eliminate the complexity.  It is nice there is an existing implementation, but is there enough value in multiple paths to continue down that road?

I have some concerns that there are a lot of cryptographic primitives here, and it doesn't look very negotiable for those primitives.  I'm hesitant to have this much specialized work happen in a group that does not have the expertise.  Would it be possible (and worthwhile) to separate this more, and possibly push the primitives through the security area?

Finally, given your original post, seeing the word "forgeability" as a feature makes me personally very nervous.  I don't claim to be an expert, or much more than a erstwhile enthusiast, but I have a hard time seeing this being a good idea in general.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

[CARBONS] XEP-0280: Message Carbons < http://xmpp.org/extensions/xep-0280.html >
[XMPP-E2E] End-to-End Object Encryption and Signatures for the Extensible Messaging and Presence Protocol (XMPP) < http://tools.ietf.org/html/draft-miller-xmpp-e2e-05 >

On Feb 26, 2013, at 7:35 AM, Jon Kristensen <[email-masked]> wrote:

> Hello, everyone!
> 
> I would like to briefly introduce myself to the members of this mailing list, and to inform you of my interest of contributing to the standardization of the use of the Off-the-Record protocol with XMPP.
> 
> My relevant past experience includes being one of the co-authors of Pontarius XMPP[1], a client XMPP library for Haskell, as well as the prototyping of a OTR-based (but (so far) OTR-incompatible) JavaScript application currently called Yabasta[2].
> 
> In the process of prototyping Yabasta, I have "designed" an OTR-like protocol[3] that, while based on OTR, differs from OTR in a number of ways. Most importantly, the OTR messages (be it the authenticated key exchange, the protected payloads, or the Socialist Millionaire's Protocol) are expressed with XML instead of with a binary encoding. Also, the prime numbers used are negotiatable, and any XML payloads can be protected (not just message bodies). (I never meant to go "Not invented here" in regards to OTR: my intention was simply to make the protocol easier to understand and to implement, more flexible, and better suitable for XMPP. However, I have since then that straying so far from OTR might not have been the best idea.)
> 
> Please don't hesitate to contact me if you are working on anything related to the above, or if you have any other questions or concerns.
> 
> Warm regards,
> Jon Kristensen
> 
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Jon Kristensen <[email-masked]>
Date: Thu, 28 Feb 2013 00:20:02 +0100

Hi Richard, and thank you for your question!

I may be wrong - I only skimmed through it, but the way I understand 
that specification, it's using public-key cryptography is used to 
encrypt and decrypt the messages. If this is the case, it would mean 
that the protocol does not offer repudiability; if Alice sends a message 
to Bob, Bob can prove that Alice (or, at least, someone with access to 
Alice's private key) has authored a message. In most off-the-record 
conversations, this would not be desirable. What OTR does is negotiates 
a shared secret (symmetric key), which is then used to encrypt and 
decrypt the messages. What this means is that Bob, having access to the 
encryption key, could have just as easily produced the message. Hence, 
Alice can deny that she authored the message in the first place.

Furthermore, the negotiation of a shared secret is continuously repeated 
in OTR in order to allow for forward secrecy. This prevents previous 
session keys from being compromised if the (long-term) private key 
happens to get compromised. I think this is another important security 
feature to keep in mind.

Best,
Jon Kristensen

---

From: Jon Kristensen <[email-masked]>
Date: Thu, 28 Feb 2013 00:33:09 +0100

Also, speaking about repudiability, I forgot to add that OTR also uses a 
malleable cryptographic algorithm (AES in CTR mode), so that the 
recipient has the means to trivially alter the ciphertext transcript and 
encryption key and have the altered transcript appear valid.

Jon

---

From: Jon Kristensen <[email-masked]>
Date: Thu, 28 Feb 2013 01:51:51 +0100

Hi Matt!

I just realized that there is another thing about myself that I should 
probably bring up. My overall vision is to generalize on the OTR 
protocol and build systems that exposes as little information as 
possible to intermediate entities, including the XMPP server. In fact, 
I'm opposed to the concepts of cloud computing and software as a service 
as a whole. I'm aiming to build client solutions that are independently 
capable and privacy-aware. In effect, I consider the XMPP server 
primarily a proxy, authenticator, and stanza router. This renders quite 
a few XMPP extensions incompatible with what I'm trying to do.

With this idea in mind, I will value properties (like repudiability and 
forward secrecy) that may not be valued by other developers. We may very 
well find that the properties that makes an end-to-end security protocol 
perfect for me, will make it overly complex for others. On the other 
hand, we may also find that the features that I value could be 
interesting for other implementations as well. Either way, I look 
forward to the discussions, and hope that there is room for my vision 
within the XMPP community.

Anyway...

In the case of OTR/Yabasta, the secure channels are negotiated between 
only two resources (and, what's worse, the symmetric key is continously 
changing in order to allow for forward secrecy), so no other client 
would be able to decrypt the forwarded message. Thus, [CARBONS] would 
seem to be incompatible with the current version of OTR/Yabasta. I'm 
currently not sure of whether or not it would be possible to extend 
OTR/Yabasta with transparent support for multiple resources. I will take 
a look at that.

The authenticated key exchange of OTR "mathematically" requires four 
messages (six if we want confirmation by empty IQ result stanzas). This 
is unfortunate, but seems necessary for the Diffie-Hellman key exchange 
(allowing for forward secrecy) as well as the hiding of the long-term 
public keys from a passive attacker. I'm looking into ways of making 
this more effective.

There's not that much difference between OTR and Yabasta from a 
cryptography point of view, so it should not be difficult to review its 
security.

You also mentioned forgeability. I'm currently investigating what the 
benefits are of this feature, and I will present my findings when I'm done.

Thanks for your reply!

Best,
Jon Kristensen

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 28 Feb 2013 02:34:14 +0000

On Feb 27, 2013, at 4:20 PM, Jon Kristensen <[email-masked]>
 wrote:

> I may be wrong - I only skimmed through it, but the way I understand that specification, it's using public-key cryptography is used to encrypt and decrypt the messages. If this is the case, it would mean that the protocol does not offer repudiability; if Alice sends a message to Bob, Bob can prove that Alice (or, at least, someone with access to Alice's private key) has authored a message. In most off-the-record conversations, this would not be desirable. What OTR does is negotiates a shared secret (symmetric key), which is then used to encrypt and decrypt the messages. What this means is that Bob, having access to the encryption key, could have just as easily produced the message. Hence, Alice can deny that she authored the message in the first place.
> 

Well, strictly speaking, the messages are protected with a symmetric key.  That symmetric key, which is exchanged separately from the message(s), is currently protected by a public key.  I suppose we could work out a key request model that utilized a different key agreement if that is important enough.

> Furthermore, the negotiation of a shared secret is continuously repeated in OTR in order to allow for forward secrecy. This prevents previous session keys from being compromised if the (long-term) private key happens to get compromised. I think this is another important security feature to keep in mind.
> 

The session key could be rotated with every message if implementations desire it.

- m&m

---

From: Richard Barnes <[email-masked]>
Date: Wed, 27 Feb 2013 22:10:57 -0500

It appears there is some conversation to be had about requirements. But it
sounds to me like there's a large degree of consistency here.

As Matt says, a lot of what Jon is talking about can be supported as
options within an overall e2e system, so that, say,  implantations that
want "malleability" can use CTR, while those with other priorities can use
authenticated encryption (say GCM).

And of course, the whole point of the e2e model is to reduce the level of
control and access that servers have.

On Wednesday, February 27, 2013, Matt Miller (mamille2) wrote:

>
> On Feb 27, 2013, at 4:20 PM, Jon Kristensen <[email-masked]<javascript:;>
> >
>  wrote:
>
> that specification, it's using public-key cryptography is used to encrypt
> and decrypt the messages. If this is the case, it would mean that the
> protocol does not offer repudiability; if Alice sends a message to Bob, Bob
> can prove that Alice (or, at least, someone with access to Alice's private
> key) has authored a message. In most off-the-record conversations, this
> would not be desirable. What OTR does is negotiates a shared secret
> (symmetric key), which is then used to encrypt and decrypt the messages.
> What this means is that Bob, having access to the encryption key, could
> have just as easily produced the message. Hence, Alice can deny that she
> authored the message in the first place.
> >
>
> Well, strictly speaking, the messages are protected with a symmetric key.
>  That symmetric key, which is exchanged separately from the message(s), is
> currently protected by a public key.  I suppose we could work out a key
> request model that utilized a different key agreement if that is important
> enough.
>
> session keys from being compromised if the (long-term) private key happens
> to get compromised. I think this is another important security feature to
> keep in mind.
> >
>
> Matt Miller < [email-masked] <javascript:;> >
> Cisco Systems, Inc.
>
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 27 Feb 2013 20:26:32 -0700

On 2/27/13 8:10 PM, Richard Barnes wrote:
> It appears there is some conversation to be had about requirements.
> 
It's funny you should say that, because Matt and I were talking just
today about how we might need to update the old requirements document:

https://tools.ietf.org/id/draft-saintandre-xmpp-e2e-requirements-01.txt

Feedback is welcome.

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jon Kristensen <[email-masked]>
Date: Thu, 28 Feb 2013 23:14:51 +0100

On 02/28/2013 03:34 AM, Matt Miller (mamille2) wrote:
> Well, strictly speaking, the messages are protected with a symmetric 
> key. That symmetric key, which is exchanged separately from the 
> message(s), is currently protected by a public key. I suppose we could 
> work out a key request model that utilized a different key agreement 
> if that is important enough.

Just to confirm: Are you saying that the current key agreement method is 
inherently incompatible with repudiability?

> The session key could be rotated with every message if implementations 

Would rotating the key in this way enable forward secrecy?

Best,
Jon Kristensen

---

From: Richard Barnes <[email-masked]>
Date: Thu, 28 Feb 2013 17:30:25 -0500

> inherently incompatible with repudiability?

Could you clarify what you mean by "repudiability"?  Do you mean that,
post-hoc, it is impossible to tell which of the parties holding a symmetric
key generated a given stanza?

The current system is explicitly *compatible* with this notion of
repudiability.  As Matt says, in the current scheme, the sender makes up a
random symmetric key and wraps it in the recipient's public key.  The
message is then encrypted under the symmetric key.  So the sender and the
receiver share a symmetric key, and either of them can modify the message
to be whatever they want.

> Would rotating the key in this way enable forward secrecy?

No.  Compromise of the recipient's private key would expose all of the
session keys.  If you want forward secrecy, you need to do DH.

--Richard

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 28 Feb 2013 23:21:51 +0000

> session keys.  If you want forward secrecy, you need to do DH.

For whatever value this adds, if an attacker:

1) has compromised the recipient's private key
2) has observed all of the encrypted traffic between the sender and the recipient
3) can communicate with the sender as if it were the recipient (to get the next session key)
4) convinces the sender the public portion of the compromised private key is still valid[1]

Then all of the past and future session keys are exposed. If any two of those conditions don't hold then some set of session keys are not exposed.

- m&m

[1] This condition has been left as "an exercise for the implementation" to determine, so might not be worth any consideration.