[Standards] [Security] Questions about authentication mechanisms

Dave Cridland dave at cridland.net
Tue Jan 13 17:33:29 UTC 2009

List change...

On Tue Jan 13 16:40:42 2009, Dirk Meyer wrote:
> Remko Tronçon wrote:
> > Dave reminded me that it could make sense to disable compression  
> after
> > TLS, namely when TLS is doing compression itself (and it doesn't  
> make
> > sense to do compression twice).
> Compressing a TLS layer makes no sense at all. So if I want  
> compression
> (and not using TLS compression itself), I would first start TLS and
> after that zlib. In that order zlib compresses XML data, the other  
> way
> around it compresses encrypted data which is much less effective.
You're convolving the order of negotiation with the order of  
application. In IMAP, for instance, you can negotiate COMPRESS, then  
TLS privacy, then SASL integrity, and still have data compressed,  
authenticated, and then encrypted - look at RFC 4978. Of course,  
you're far more likely to want to negotiate TLS, COMPRESS, then SASL,  
and elide the COMPRESS if TLS gave you compression.

> But maybe the choices here are TLS with compression in TLS _or_  
> zlib and
> no TLS. But IMHO TLS should be mandatory which raises the question  
> if we
> need zlib compression at all.

But TLS compression isn't, sadly, always available, and even in cases  
where it's possible to kick the TLS implementation into negotiating  
compression, it's usually much easier to support XEP-0138.

RFC 4978 has, basically, this discussion as its introduction. Section  
4 is particularly interesting, and it's almost a shame that it  
doesn't really apply to XMPP in the slightest.

Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the Standards mailing list