Subject: [xmpp] Problems with draft-miller-xmpp-e2e [WAS: [Standards] Updated Yabasta Protocol (E2E-related)]

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 11 Jul 2013 13:09:46 +0000

Forwarding to the proper discussion venue...

Begin forwarded message:

> From: Peter Waher <[email-masked]>
> Subject: FW: [Standards] Updated Yabasta Protocol (E2E-related)
> Date: June 27, 2013 1:59:40 PM MDT
> To: "Matt Miller ([email-masked])" <[email-masked]>
> 
> Hello Matt
> 
> Anything you would like to comment on, on the standards list?
> 
> Sincerely,
> Peter Waher
> 
> -----Original Message-----
> From: Jon Kristensen [mailto:[email-masked]] 
> Sent: den 27 juni 2013 15:30
> To: Peter Waher
> Cc: XMPP Standards
> Subject: Re: [Standards] Updated Yabasta Protocol (E2E-related)
> 
> Hi Peter, and thank you for your response!
> 
> These are the problems of the draft as I understand it.
> 
> It does not offer perfect forward secrecy, as the compromise of a private key would unlock all of the session keys protected by the corresponding public key.
> 
> It also does not allow for anonymity (neither weak or strong), as the public key is being sent in the clear.
> 
> A Diffie-Hellman key exchange request model could be used to tackle these problems, provided that two levels of <keyreq /> requests can be used. I don't know if this is part of the indended usage of the draft, or whether or not it would actually work. It would be great to see, though! Has any work been done to accommodate this feature?
> 
> I'm also a little concerned about the fact that the public keys is used to protect the session keys from a deniability perspective, but I haven't really thought that through enough yet. Maybe it's nothing...
> 
> Thanks again!
> 
> Jon
> 
> On Thu, 2013-06-27 at 17:25 +0000, Peter Waher wrote:
>> Hello Jon
>> 
>> Have you considered using the proposed draft for end-to-end encryption available at IETF?
>> http://tools.ietf.org/html/draft-miller-xmpp-e2e-06
>> 
>> Sincerely,
>> Peter Waher
>> 
>> -----Original Message-----
>> From: Jon Kristensen [mailto:[email-masked]]
>> Sent: den 26 juni 2013 14:16
>> To: [email-masked]
>> Subject: [Standards] Updated Yabasta Protocol (E2E-related)
>> 
>> Hello everyone!
>> 
>> The OTR-inspired and end-to-end secure Yabasta protocol has received a significant update today. You can see the updated protocol at <https://github.com/jonkri/yabasta-protocol/>.
>> 
>> The protocol now supports a higher degree of anonymity than it did 
>> before. The public key is no longer automatically transferred in the 
>> authenticated key exchange (as is the case with the Off-the-Record 
>> protocol). Instead, the key exchange only exposes a signature. Users 
>> can then perform various identity verification actions (such as
>> "challenges") to increase their trust in the remote peer before they reveal their public key. This is done so that clients can choose to consider their public keys a secret credential, and not automatically reveal their public keys to an active man-in-the-middle attacker.
>> 
>> The protocol has also been made more flexible. Clients can now configure things like what prime numbers to use for the Diffie-Hellman calculations, as well as what cryptographic and signing algorithms to use. Other updates include a separation between the abstract method and the actual protocol implementation, various clean-ups, and additional explanations to make the document easier to understand.
>> 
>> Feedback is more than welcome! :-)
>> 
>> Thanks!
>> 
>> Jon Kristensen
>> 
>> 
> 
> 
> 
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2013.0.3345 / Virus Database: 3204/6445 - Release Date: 06/27/13

- m&m

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

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Thu, 11 Jul 2013 13:20:51 +0000

Hello Jon,

>> It does not offer perfect forward secrecy, as the compromise of a private key would unlock all of the session keys protected by the corresponding public key.

We talked about this on this list, and agreed that some form of "pure" DH agreement would be a way to address this, as well as remove the requirement for RSA keys.  I've been spending more energy on other tasks, and haven't had the time to work this out for myself.

As stated previously, suggested texts for draft-miller-xmpp-e2e are welcome.  If you can be in Berlin between 07/26 and 08/02, we can even sit down and hash something out face-to-face!

>> It also does not allow for anonymity (neither weak or strong), as the public key is being sent in the clear.

See above.

>> A Diffie-Hellman key exchange request model could be used to tackle these problems, provided that two levels of <keyreq /> requests can be used. I don't know if this is part of the indended usage…

See above.

>> I'm also a little concerned about the fact that the public keys is used to protect the session keys from a deniability perspective, but I haven't really thought that through enough yet. Maybe it's…

I don't have empirical evidence to back this up, but seems to be there are at least as many people that want non-repudiation than there are people that want deniability.  While the two are mutually exclusive, I don't think it means it can't be done.

The draft uses JWK objects for keys.  As long as you can represent the DH agreement as a JWK, I don't see why you couldn't use that instead of an RSA public/private key pair.

- m&m

---

From: Jon Kristensen <[email-masked]>
Date: Sun, 14 Jul 2013 19:09:11 +0200

Hi, Matt!

I see. Thank you for your clarifications. I'm really glad that you're
open to look into meeting these (to me, very important) requirements.
PFS, repudiability, and anonymity (preferably strong) are "MUST"
requirements for the system that I'm building, and that's why I'm
developing the Yabasta protocol.

Unfortunately, as I'm quite busy with other matters, I don't think
that I will be able to contribute much to your draft, at least not
during the summer. I will not be able to travel to Berlin during those
days, either. :-( However, I will be following this mailing-list for
further developments of your drafts, and I hope that I will find the
time to review any suggestions related to the above.

Good luck!

Jon

On Thu, 11 Jul 2013 13:20:51 +0000
"Matt Miller (mamille2)" <[email-masked]> wrote:

> >> It does not offer perfect forward secrecy, as the compromise of a
> >> private key would unlock all of the session keys protected by the
> >> corresponding public key.
> >> 
> 
> We talked about this on this list, and agreed that some form of
> "pure" DH agreement would be a way to address this, as well as remove
> the requirement for RSA keys.  I've been spending more energy on
> other tasks, and haven't had the time to work this out for myself.
> 
> As stated previously, suggested texts for draft-miller-xmpp-e2e are
> welcome.  If you can be in Berlin between 07/26 and 08/02, we can
> even sit down and hash something out face-to-face!
> 
> >> It also does not allow for anonymity (neither weak or strong), as
> >> the public key is being sent in the clear.
> >> 
> 
> See above.
> 
> >> A Diffie-Hellman key exchange request model could be used to
> >> tackle these problems, provided that two levels of <keyreq />
> >> requests can be used. I don't know if this is part of the indended
> >> usage of the draft, or whether or not it would actually work. It
> >> would be great to see, though! Has any work been done to
> >> accommodate this feature?
> >> 
> 
> See above.
> 
> >> I'm also a little concerned about the fact that the public keys is
> >> used to protect the session keys from a deniability perspective,
> >> but I haven't really thought that through enough yet. Maybe it's
> >> nothing...
> >> 
> 
> I don't have empirical evidence to back this up, but seems to be
> there are at least as many people that want non-repudiation than
> there are people that want deniability.  While the two are mutually
> exclusive, I don't think it means it can't be done.
> 
> The draft uses JWK objects for keys.  As long as you can represent
> the DH agreement as a JWK, I don't see why you couldn't use that
> instead of an RSA public/private key pair.
> 
> 
> - m&m
>