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
