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

[Martin Rex <mrex at sap.com>]

Yoav Nir wrote:
> 
> David-Sarah Hopwood wrote:
> 
> > Marsh Ray wrote:
> >
> > To prevent this attack, they don't have to disallow connections, only
> > renegotiations in which the extension is not used.
> 
> Even that can be further refined. You can freely renegotiate an
> authenticated session, as long as the renegotiation does not involve
> an identity change.
> 
> Obviously, if the first handshake include client authentication,
> any renegotiation that includes the same client cert is fine.


I whish there was a constraint that an identity/certificate that has
been established for a party during the TLS handshake MUST not change
during re-negotiation, but _none_ of the current SSL&TLS specs has
such a constraint, so the issue of identity change is currently
dumped as a responsibility onto the application.

I am certainly in favour of locking this down for the renegotiation.
I believe it is irresponsible to leave this un(der)specified as it is.

We can be lucky if the application performs an authentication at all.
since there currently is absolutely no signalling defined that would
tell an application reliably at which point of the stream a
renegotiation was completed, the app doesn't know (a) when to
perform an additional authentication and (b) where the data
from the previous session ends and where the next starts.

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.

There are software architectures where the server certificate is checked
in a callback style when processing the ServerCertificate handshake
message (both: PKI-verification and server endpoint identification),
Application data protected under the old encryption could be exchanged
after the processing of the ServerCertificate and before the
ChangeCipherSpec (i.e. protected under the old session), and
also between ChangeCipherSpec and Finished messages (protected
under the new session, but before the finished messages have verified).


The semantics for the initial TLS handshake on a connection are
*MUCH* cleaner (both full TLS handshake and session resume):
no application data may be exchanged before the finished messages
have been verified.

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

Since the original streams in both directions could have been used
in completely asynchronous fashion, both peers may have to get back
in sync for the renegotiation, recognizing that they're in sync by
receiving the first handshake message (ClientHello/ServerHello).

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)?


-Martin