Re: [TLS] TLS renegotiation issue

[Martin Rex <mrex at sap.com>]

Eric Rescorla wrote:
> 
> Marsh Ray, the initial discoverer, has been working with a bunch of
> people in the security community to deal with this issue and develop
> a fix. Tomorrow AM I'll be posting an initial draft that describes
> the obvious fix, which is to cryptographically bind negotiations
> to any enclosing connection (if any). I won't be in Hiroshima but
> I expect the WG will want to discuss this topic.


One conceivable approach would be a TLS extension for secure renegotiation
with roughly the following semantics:


 - on initial TLS handshakes (aka Re-nego of a TLS_NULL_WITH_NULL_NULL)
   the client that supports secure renegotiation should send the
   TLS extension in the client hello with an empty extension data
   to signal to the server that it support secure renegotation.

 - on TLS session renegotiations, the client should sent the TLS extension
   with the extension data containing the client.random and server.random
   from the existing session.

 - A server that receives a ClientHello without the TLS extension for
   secure renegotiation should NOT perform old-style renegotiation
   for that session (and get apps with flawed assumptions into trouble),
   i.e. NOT support delayed authentication for those TLS clients.

 - A server that receives a ClientHello on an initial TLS handshake
   with a TLS extension (empty data) for secure renegotiation may decide to
   delay client-cert authentication to a securely renegotiated session

 - A server that receives a ClientHello with a TLS extension for secure
   negotiation and a reference to a previous session MUST compare the
   client.random and server.random from the extension data to that of
   the current session (and abort if they do not match).  And the
   server should probably insist on doing a ChangeCipherSpec on both
   directions in the renegotiation handshake.


Since Larry is looking for a means to uniquely identify a single
TLS "connection" independent of whether its a single TLS handshake
or renegotiated, we should check whether we can carry-over some
information form the initial handshake on a connection along
with the client.random&server.random.  Technically there is no
limit on the number of renegotiations, so a simple pointer
only one TLS session into the past does not seem sufficient
for that purpose.



-Martin