Stream feature negotiation ordering. Was: Re: [jdev] S2S questions - from attribute and version support

[Dave Cridland]

On Thu Apr 27 18:51:32 2006, Michal vorner Vaner wrote:
> On Thu, Apr 27, 2006 at 07:34:21PM +0200, Matthias Wimmer wrote:
> > Peter Saint-Andre schrieb:
> > >Stream compression is negotiated when you can't set the TLS > 
> >compression bit for whatever reason. I'd agree with Ralph that > 
> >negotiating this after TLS and before SASL (or jabber:iq:auth) 
> makes > >the most sense. So:
> > >
> > >1. TLS
> > >2. Stream compression
> > >3. SASL etc. (or jabber:iq:auth)
> > > I think stream compression should be negotiated AFTER doing 
> SASL. The > reason is that some SASL mechanisms can establish an 
> encryption layer. > If SASL encrypts the stream, stream compression 
> would not work anymore.
> > Negotiating stream compression after doing SASL would result in 
> being > the stream first compressed and encrypted afterwards - 
> which works.
> > 
> Well, as I know, the compression can be done in TLS, not SASL. SASL 
> is
> only few stanzas at the beginning to send a password, whilest the 
> whole
> stream is piped trough the TLS only usually, right? And it is a good
> place for it anyway, as encryption makes the data look more
> unpredictable, which is good for encryption.
> 
> 
SASL can also provide privacy and/or integrity, too. It can provide 
strong encryption in fewer round-trips than TLS, as well. And 
usually, SASL doesn't send a password - it only does so with PLAIN 
and the non-standard LOGIN mechanisms.


> I'm not expert for either of them, but I guess compresion in TLS 
> makes
> sence, in SASL doesn't..
> 
> 
A SASL mechanism could provide compression. None do, as far as I 
know, but they could.

In any case, the important factor isn't so much when the compression 
gets negotiated, but where it's applied - compression is adding a 
layer into the stack. Normally, it's easiest to add a layer in at the 
top of a running connection, so you'd add it in after any encryption 
has been negotiated.

If you know you're not going to negotiate a privacy/intergrity layer 
in SASL, you could negotiate it beforehand, thus compressing the SASL 
exchange for a slight saving. On a server, you could refuse to 
provide encryption/integrity via SASL if compression was in effect, 
or you could assume the client knew what it was doing if you were 
capable of inserting a layer.

So it's typically going to be one of:

1) TLS -> Comp -> SASL(no encrypt)
2) SASL(encrypt) -> Comp
3) TLS -> Comp -> Auth

(and non recommended)

4) Comp -> Auth
5) Comp -> SASL(no encrypt)

And always, the result should be that data is first compressed, then 
any SASL encoding is applied, then any TLS.

In general, SASL exchanges compress by around 20% on ESMTP, IMAP, and 
XMPP because they're base64 encoded. In ACAP (and presumably LDAP, 
although I've not looked), they don't compress as well because 
they're transmitted in binary.

By the way, I was meaning to ask why the stream compression mechanism 
uses zlib format rather than just deflate blocks? zlib just 
introduces overhead - it's for compressing files, not streams. TLS 
(and both application-level compression proposals for IMAP) use pure 
deflate. HTTP uses gzip and zlib (confusingly it calls zlib 
"deflate"), but then, it's designed to handle precompressed files on 
the server, so this is a somewhat different circumstance.

Dave.
-- 
           You see things; and you say "Why?"
   But I dream things that never were; and I say "Why not?"
    - George Bernard Shaw