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

[Michal vorner Vaner]

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.

I'm not expert for either of them, but I guess compresion in TLS makes
sence, in SASL doesn't..

-- 

NAT should extinkt like dinosaurs did.

Michal "vorner" Vaner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20060427/2eac4a39/attachment-0002.pgp>