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

[Jon Kristensen <[e-mail]>]

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)" <[e-mail]> wrote:

> Hello Jon,
> 
> >> -----Original Message-----
> >> From: Jon Kristensen [mailto:[e-mail]] 
> >> 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.
> >> 
> 
> 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
> 
> Matt Miller < [e-mail] >
> Cisco Systems, Inc.
>