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 protected]] > Sent: den 26 juni 2013 14:16 > To: [email protected] > 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 > >
