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

[Martin Rex <[e-mail]>]

Michael D'Errico wrote:
> 
> I disagree.  When you receive the ChangeCipherSpec, the new parameters
> take effect; the Finished message has to immediately follow to verify
> the handshake succeeded.  Verification of the Finished message signals
> the end of the old session and the beginning of the new.

Correct.  This is what rfc5246 (TLS 1.2) specified in 7.4.9 Finished
message when describing the handshake protocol.

Unfortunately there is a slightly confusing disagreement with the
description of the SSL Record protocol (which is a logically seperate
thing and often also a seperate sofwarer layer).  As mentionend in
a previous message, the final paragraph of 6.2.1 Fragmentation
in the description of the Record Layer Protocol says this to
implementors:

   Note: Data of different TLS record layer content types MAY be
   interleaved.  Application data is generally of lower precedence for
   transmission than other content types.  However, records MUST be
   delivered to the network in the same order as they are protected by
   the record layer.  Recipients MUST receive and process interleaved
   application layer traffic during handshakes subsequent to the first
   one on a connection.

If a company subscribes to agile software development with Scrum and assigns
the implementation of the TLS record layer and of the TLS handshake protocol
to different Scrum teams, you may be surprised with the result on this
point of the spec. :-/


> 
> > But that will not affect the miserable ambiguity for where the
> > original session ends and the new session starts if we do allow
> > established identities to change during renegotiation.
> 
> The CCS/Finished tells you where to draw the line.

If the server implementation that you're looking at uses a
callback scheme similar to OpenSSL, then the application might
have hardwired the update of the client authentication state
(as seen by the app) to the callback that is called when processing
the clients certificate verify message.  At that point, the
session is still in the clear for an attacking MITM, and that
MITM might start inserting application records that the server
will receive at a point where it thinks the client is authenticated
(which it is, just that the client authentication is tied to
an encrypted channel that is still being negotiated and has
not yet been confirmed for the current session yet...

Does OpenSSL offer a callback for the finished messsage of
a renegotiation, and which OpenSSL-based server is using that callback?


I would be OK with interleaving application data with handshake
message for the case where TLS enforces a lockdown of the communicating
identities. 

I really don't like to allow both, change of identities during
renegotiation _and_ arbitrary interleaving of application data
with the renegotiation handshake messages.  Applications
may get this wrong easily.


For earthbound TLS connections a rekeying of a TLS connection
through renegotiation while application data continues to flow
is probably not an issue.  It might become an issue for a link to
a space vehicle further out (like a moon of jupiter),
where one might want to continue transfering a few gigabytes of data
while the TLS renegotiation (for the purpose of rekeying) is performed...


-Martin