[Standards-JIG] stream restarts

Peter Saint-Andre stpeter at jabber.org
Thu Sep 14 21:05:32 UTC 2006

Well, I talked about this with someone smarter than me (Joe Hildebrand),
who reminded me that we need the stream restarts in order to protect the
stream headers from man in the middle attacks (rewriting of 'to' and
'from' addresses, etc.), at least (1) after TLS negotiation and (2)
after SASL negotiation when SASL negotiation involves installation of a
security layer. We don't need it after things like stream compression,

So I retract the email quoted below.


Peter Saint-Andre wrote:
> A while back, Matthias Wimmer proposed that we define an option for not
> doing stream restarts in rfc3920bis:
> http://mail.jabber.org/pipermail/standards-jig/2006-August/011954.html
> I took it as an action item to investigate why the stream restarts were
> there in the first place and whether we really need them:
> http://mail.jabber.org/pipermail/standards-jig/2006-August/012058.html
> I've done the research and I don't think we need to do the stream
> restarts, at least not in order to comply with the TLS spec, since
> Section 7.1.2 of RFC 4346 says:
>    If the application protocol using TLS provides that any data may be
>    carried over the underlying transport after the TLS connection is
>    closed, the TLS implementation must receive the responding
>    close_notify alert before indicating to the application layer that
>    the TLS connection has ended.  If the application protocol will not
>    transfer any additional data, but will only close the underlying
>    transport connection, then the implementation MAY choose to close the
>    transport without waiting for the responding close_notify.  No part
>    of this standard should be taken to dictate the manner in which a
>    usage profile for TLS manages its data transport, including when
>    connections are opened or closed.
> There's nothing in RFC 4422 (SASL) that would influence whether we have
> restarts, either.
> So, as far as I can see, we don't absolutely need the stream restarts.
> Therefore, I don't have any objections to defining an OPTIONAL method
> that the initating entity and receiving entity can agree on so that they
> won't do stream restarts during a given session. Presumably we'll do
> that with a new stream feature. I'll post again soon with some thoughts
> about how we might do that.
> Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060914/18f94ab3/attachment.bin>

More information about the Standards mailing list