On Thu, 2013-06-27 at 12:01 +0100, Simon McVittie wrote: > On 26/06/13 19:16, Jon Kristensen wrote: > > 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/>. > > Why should implementers prefer this protocol over end-to-end TLS, such > as the XTLS RFC-draft? Sell it to us :-) > > (I do like this better than OTR, because the payload is specifically an > extensible XMPP stanza, rather than being constrained to be > human-readable text in UTF-8 "optionally with HTML markup", whatever > that means.)
Hi, and thanks for your reply! :-) We could have used OTR and allowed for wrapped stanzas instead (in a way that doesn't conflict with exiting OTR applications), but OTR has other problems, such as the fact that the prime numbers and encryption algorithms are static, and that OTR is also coupled with its binary implementation, which (in the case of XMPP usage) makes it much less extensible. For bootstrapping trust prior to revealing the certificates, TLS supports one-time passwords through SRP (the Secure Remote Password protocol). This is less flexible and extensible than the challenges concept used in the Yabasta protocol. Like SRP, Yabasta challanges (using the Socialist Millionaire algorithm) can be used to provide strong security using weak passwords, but the challenges can also be used to ask arbitrary questions to the peer (and can be extended to support other use cases as well). This helps making the identity management tasks significantly easier for the users. Also, the Yabasta protocol supports deniability/repudiability. As far as I can tell, TLS cannot do so in an authenticated mode. Finally, in XTLS, the fingerprints of the certificates does not seem to be protected. As such, an eaves-dropper will be able to prove which certificates were involved, should the attacker manage to acquire the certificates somehow. (OTR is even less secure in this regard, as it automatically announces the public key as part of the key exchange.) The Yabasta protocol only reveals a signature (to the remote peer or an active attacker), and does as such provide a higher degree of anonymity. > Most client implementers haven't implemented XTLS, and the RFC-draft for > it wasn't finished, because end-to-end security is a lot of work to do > well (or at least, that's why nobody has had time to implement it in > Telepathy). Is Yabasta any easier, bearing in mind that unlike XTLS, it > doesn't appear to be possible to use existing TLS libraries like GNUTLS, > NSS or OpenSSL to do the cryptographic bits? It is unfortunate that TLS does not seem to be able to solve this problem, but luckily, the Yabasta protocol is quite simple. Also, current OTR libraries (such as libotr) should be able to be modified to work with the Yabasta protocol quite easily. > > a service discovery feature item of "yabasta-protocol:0" > > That's not an IETF-registered URI scheme, and neither are the various > XMLNSs in your mapping into XMPP. If you own yabasta.com, > http://yabasta.com/xmpp/0 might be a more appropriate URI, for instance. > (If you don't, please don't it in your examples :-) > > You probably only need one XMLNS for the whole specification: only the > tuple (namespace URI, element name) needs to be unique. > > Regards, > S > Thanks! Jon
