Re: [TLS] Avoiding first use of RI in ClientHello

[Eric Rescorla <[e-mail]>]

At Wed, 25 Nov 2009 15:28:28 -0800,
Robert Relyea wrote:
> > It's unclear how often such fall-back logic would actually be needed,
> > and I do find Nelson's "tough love" approach here sort of appealing,
> > but it does seem to be a problem that you don't necessarily know for sure 
> > whether you need it or not until you've actually shipped the product 
> > with extensions, and possibly broken applications that currently work. 
> > It's especially concerning that fall-back can't be implemented reliably
> > inside the TLS library, e.g., if you just get a filehandle, so changes
> > to the app logic are required.
> >   
> I think we already have a handle on this. Most modern browsers already
> send extensions in their initial handshakes. This change has been
> responsible for the final demise of SSLv2.
> 
> The whole idea that extensions are rare just doesn't match with today's
> reality. Yes, there are some implementations that can't handle them.
> That is a very small percentage compared to the number of
> implementations that can't safely renegotiate (e.i. 100% of them). Those
> implementations already have to deal with a world in which extensions
> are real and common. They also have to deal with a world in which their
> code will need to be patched in order to be safe anyway.
>
> > The rest of this message describes a simple modification [*] to
> > draft-ietf-tls-negotiation which I think addresses this compatibility
> > issue without requiring fall-back.
> >
> > The idea is to use a magic cipher suite to signal that the client can
> > securely renegotiate (as described in
> > draft-mrex-tls-secure-renegotiation). 
> I'm not excited about the magic cipher suite hack for SSLv3, but I can
> live with it if I have to. I am strongly opposed to extending it to TLS.
> In the TLS world extensions are expected, normal, and now common. There
> is no reason to overload a field created specifically to determine a
> compatible cipher suite with something that extensions are designed to do.

I'd be very interested in seeing data on what fraction of existing
servers can't handle extensions. Is there any chance that you have
measurements?

Thanks,
-Ekr