Re: [TLS] assert TLSext in renego-ServerHello instead of disable

[Bodo Moeller <[e-mail]>]

On Nov 15, 2009, at 4:10 PM, Martin Rex wrote:
> Eric Rescorla wrote:
>>
>> Bodo Moeller wrote:

>>> Why make a client send it on the initial handshake if that client
>>> wouldn't have plans to abort the connection if the server doesn't
>>> acknowledge it?  Interoperability seems easier if you don't send it.

>> Agreed. I've rethought this point since I wrote it.

> I see value in extension-less signaling on initial handshake,
> because it will immediately provide protection to updated clients
> when the server is updated even when both, client and server still
> support the insecure renegotiation (i.e. very early in the
> transition period) or the client still allowys a reconnect
> fallback with an extension-less ClientHello.

Thanks, I can see your point.

My assumption was that we wouldn't mind breaking legacy renegotiation  
handshakes (we'd expect all servers that allow renegotiation to be  
updated such that they *never* allow legacy renegotiation), and that  
we'd just want *initial* handshakes to continue to work between  
updated clients and current servers.  That's just enough backwards  
compatibility such that client-side users can actually update their  
software without having to wait for all servers to get updated first.

I'm not convinced that we'd want updated servers to offer legacy  
renegotiation, but if we do, then using a pseudo ciphersuite seems  
fine to let the client indicate that it doesn't want legacy  
renegotiation (i.e., the present handshake is not a renegotiation  
handshake, and if the servers sees it as one, it should abort the  
connection immediately because it's with a MitM).

Bodo