[Standards] end-to-end encryption meeting

Peter Saint-Andre stpeter at stpeter.im
Fri Nov 9 22:31:17 UTC 2007

Justin Karneges wrote:
> On Thursday 08 November 2007 3:34 pm, Peter Saint-Andre wrote:
>> In general, we decided (again?) that only ESessions and XTLS really make
>> sense to pursue further (i.e., not OpenPGP, S/MIME, OTR, or xmlenc).
> To explain:
>   - At the meeting, Perfect Forward Secrecy (PFS) was decided to be a 
> requirement (maybe this same decision was made in the past, but this was the 
> first meeting I was involved in to witness it).  This decision essentially 
> rules out public-key based object encryption (OpenPGP, S/MIME).  Note that 
> this does not necessarily rule out using those formats for signing or trust 
> bootstrapping.
>   - OTR basically offers the same security features as Esessions.  Both are 
> not proven, but Esessions fits XMPP better.
>   - xmlenc symmetric encryption could have been considered as a building block 
> for Esessions, but I assume this was already decided against.

As far as I understand it, xmlenc by itself does not offer perfect
forward secrecy. Plus I think there are many interoperability issues
with xmlenc/xmldsig.

> This leaves only Esessions and XTLS to be analyzed further.
> Esessions claims to do everything we want.  However, it is not proven.  Last 
> time we invited security folks to inspect Esessions, we were immediately told 
> to give up and just use S/MIME.  

In fact, at least one of them told us to look into an application
profile of TLS (thus "XTLS"). Two other security folks we approached
said that a formal review of ESessions would take a long time and
therefore be expensive. One security person we approached said that
ESessions looked like a good concept but he did not have the bandwidth
to offer a more formal review.

You may be remembering what happened when we took our core protocols to
the IETF. At that time we used OpenPGP (XEP-0027) and we were told that
we couldn't use that but had to define an S/MIME-based technology
instead, which is how we ended up with RFC 3923.

> We don't want to use S/MIME, because it 
> doesn't support PFS.  


> However, we also don't want to give the finger to the 
> security community.  

Generally not a good idea, no. At least when you're trying to get your
protocols approved by said community. :)

> That leaves us with one choice really: look for a
> similarly proven protocol that meets our requirements.  The closest match 
> seems to be TLS (hence, XTLS).

Right. So we need to look at ESessions and XTLS from the perspective of
complying with the requirements defined in XEP-0210.


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7338 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20071109/e654f639/attachment.bin>

More information about the Standards mailing list