[Standards-JIG] Re: proto-JEP: Proposed Stream Feature Improvements

[Dave Cridland]

On Tue Aug 22 16:44:26 2006, Peter Saint-Andre wrote:
> I don't know if we ever had consensus on this. IIRC, the stream 
> restarts
> are there to conform with some requirements (or our understanding of
> some requirements) from the TLS and SASL RFCs. I'm all for a clean
> design but I will look at RFCs 4346 (TLS 1.1) and 4422 (SASL) -- 
> which
> obsolete RFCs 2246 and 2222 respectively -- to make sure that we 
> would
> be in compliance if we removed the stream restarts.

There's no such requirements in RFC2246 and RFC2222 as far as I know, 
either.

However, there are security requirements in as much as you need to be 
able to get, for example, a new list of supported SASL mechanisms 
after the introduction of a TLS security layer, to avoid an MITM 
downgrade attack.

RFC3920 doesn't have a mechanism to obtain a new set of stream 
features outside of starting a new stream, so I suspect the stream 
restart was the simplest option, and it has the additional benefit of 
forcing clients to do the right thing.

What you could do is provide not only the addition 
<i-do-not-need-a-stream-restart/> feature (catchy, eh?), but require 
that clients explicitly use such a feature by adding a 
<okay-just-send-me-the-stream-features-afterward-then/> element, 
which'd resend the stream features after a layer insertion is 
complete. There's a problem here, though, which is that the client's 
stream start can be pipelined with the end of the TLS negotiation, so 
in that case at least, you gain nothing.

For SASL, you can negotiate a security layer too, and therefore a 
client will need to discard previous features and refetch them.

Perhaps the answer there is to send stream features anew immediately 
after a security layer is established by SASL - if one is.

For compression, no stream restart is needed - you just have to 
ensure that both sides know when the compression layer kicks in.

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