Re: [TLS] draft-rescorla-tls-renegotiate and MITM resistance

[Michael D'Errico <mike-list at pobox.com>]

> As previously described in another message, the current spec has a
> requirement that additonal application data may be arbitrarily
> interleaved with a renegotiation handshake.  I think this requirement
> makes a security assessment of the protocol impossible for changing
> identities.

If your TLS API was able to tell you exactly where in the application
data stream a renegotiation has completed successfully, you would
be able to apply the original security parameters to the data received
prior to the renegotiation, and then switch to the new parameters for
the data received after the renegotiation.

That would catch the MITM attack being discussed now.

> Personally, I would it find much cleaner if the semantics for the
> renegotiation would require the TLS peers to suspend transmission
> of application data while performing TLS renegotiation,
> i.e.
>
>    the client must not send any application data between
>    ClientHello and the client's Finished message
>
>    the server must not send any application data between
>    ServerHello and either no_renegotiation alert or
>    the server's Finished message 
>
>    the client must drop all application data received
>    between ServerHello and either no_renegotiation alert
>    or the server's Finished message
>
>    the server must drop all application data received
>    between the ClientHello and the client's Finished message

When I first implemented TLS, the only reason I could envision for
renegotiation was to refresh the symmetric keys, so I made it work
asynchronously.  I wrote about it in this message:

  http://www.ietf.org/mail-archive/web/tls/current/msg04042.html

With this design, application data can flow at nearly full speed while
a renegotiation is taking place.  Requiring all data to stop flowing
during a renegotiation, may be unnecessary in some situations.  I do
see however, that data probably needs to stop flowing after sending
a Finished message until receiving the peer's Finished message, but
that affects only one direction and last for one round trip, not two.

When you add changing client credentials to the mix, then data flow
probably has to stop, but that is really an application-level decision.
Also silently dropping data never seems like the right thing to do IMHO.

> Are there currently applications that actively abuse the possibility
> provided by the spec to interleave application data and handshake
> messages of a TLS renegotiation handshake (provided that the
> TLS implementation that (a) they're using and (b) they're talking
> to actually allow this.  The fact that the spec says so, doesn't
> mean that everyone has implemented it in this fashion (since it
> is complex,difficult and possibly insecure)?

Yes, see the above referenced message.  But I don't agree that it's
abuse since that is what the spec. says to do.

Mike