Re: [TLS] simplistic renego protection

 

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On 
> Behalf Of Martin Rex
> Sent: Sunday, November 15, 2009 4:37 PM
> To: tls@ietf.org
> Subject: [TLS] simplistic renego protection
> 
> The most simplistic approch to renego protection is
> 
>    1. the client signals that it is patched through a fake
>       ciphersuite ID in each ClientHello
> 
>    2. the client only supports secure renegotiation and
>       secure renegotiation is specified to change the definition
>       of the handshake message hash for renegotiation handshakes
>       to include the verify_data of the client.finished and
>       server.finished after the ServerHello.
> 
> Everything else is options for vendors and users.
> 
> If we do not provide a standardized signaling Server->Client 
> in the client hello, then it is not possible for the clients 
> to offer the option for insecure renegotiation (I have no 
> idea whether such a desire exists, but it might easily exist 
> during transition).
> 
> With this simplistic approach, an MITM can not proxy a 
> clients initial handshake into an updated servers 
> renegotiation, even when the server still allows insecure 
> renegotiation (e.g. during the transition period).  
> 
> 
> I really like to hear convincing arguments why we need the 
> TLS extension in the renegotiation handshake, and why 
> changing the definition for the handshake message hash 
> instead is not a superior alternative.  In particular one 
> that will grow naturally into future TLS revisions.
> 
[Joe] TLS Extensions is the standard way to extend the protocol.  Using
the ciphersuite field as a means to change the base protocol is a new
extension mechanism.  I don't think this is a particularly good thing
for TLS to grow into.  I don't see a reason to define a new extension
mechanism when we can achieve what is necessary using the existing
mechanism.   When TLS 1.2+x is defined in the future then it can address
the renegotiation problem as necessary and the version field will signal
the underlying changes.   


> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>