[Security] TLS Certificates Verification

[Peter Saint-Andre]

/me takes a deep breath

Dave Cridland wrote:
> On Tue Aug 19 22:19:31 2008, Jonathan Schleifer wrote:
>> "Eric Rescorla" <ekr at rtfm.com> wrote:
>>
>> > There's something truly ironic about someone lobbying for an entirely
>> > new and unanalyzed cryptographic protocol suggesting that using the
>> > most widely implemented crypto protocol in the world would be
>> > reinventing the wheel.
>>
>> There would be several changes needed as already stated on this
>> list. And new XEPs would need to be created. XEPs for stuff for which
>> already XEPs exist. If that's not reinventing, I don't know.
> 
> Actually, the XTLS proposal in its current form consists of XEP-0246, 
> which is virtually all boilerplate, and just says "negotiate a XMPP 
> stream", and XEP-0247, which says "figure out a way to talk to each 
> other using Jingle, first".
> 
> So there's new stuff, sure, but it's not reinventing by any stretch - 
> this stuff can be used and reused in multiple ways, not just for 
> end-to-end authentication and privacy. In fact, XEP-0246 just abstracts 
> out that part of the link-local messaging we've had for ages.
> 
> Inventing ESessions out of the blue most certainly *is* reinventing, or 
> at the very least was at the time. It's hard to suggest in any 
> reasonable way that ESessions is going to be as strong, 
> cryptographically, as TLS is; it's similarly hard to propose that the 
> implementations of it will be as hardened as the likes of OpenSSL.
> 
> Admittedly, it's painful throwing away that volume of work, but I think 
> it's the right choice here.

I agree this is painful. Ian Paterson put a *lot* of work into ESessions 
but did a bit as well, and I don't like to throw that away. However, I 
have slowly come to the same conclusion: it would be better to re-use 
TLS for end-to-end streams (and we already use it for c2s and s2s 
streams so it's not that much of a stretch to use it for the e2e case). 
It's never easy to admit that sunk costs are simply sunk, but sometimes 
that's the best thing to do.

> If the additional properties of ESessions are of interest, we could of 
> course work toward putting them into TLS - deniability in TLS would be 
> instantly applicable to any other protocol which needs it, for instance. 
> That might include SIP, I suppose.

As mentioned, I don't think deniability has any real meaning (do you 
think purely cryptographic deniability would hold up in a court of law? 
I don't!). But SAS for TLS seems to be interesting to some people, as we 
have recently discussed on the main TLS list:

http://www.ietf.org/mail-archive/web/tls/current/msg02832.html

/psa
-------------- 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/security/attachments/20080819/ff870edf/attachment-0001.bin