Stream feature negotiation ordering. Was: Re: [jdev] S2S questions - from attribute and version support
dave at cridland.net
Thu Apr 27 13:21:25 CDT 2006
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
> only few stanzas at the beginning to send a password, whilest the
> 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
> 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.
You see things; and you say "Why?"
But I dream things that never were; and I say "Why not?"
- George Bernard Shaw
More information about the JDev