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

[Robert Relyea <[e-mail]>]

On 11/25/2009 02:35 PM, Eric Rescorla wrote:
> Folks,
>
> I wanted to try to resolve what I see as the major technical concern
> people have about draft-ietf-tls-renegotiation-00, namely that the
> client cannot offer secure renegotiation and be sure that it won't
> cause a connection failure with a downrev (extension noncompliant)
> server.
>
> There's been a lot of discussion of whether this is a serious problem,
> but it's clear that minimal risk of breaking things that currently
> work (which some folks think requires not using extensions in the
> initial ClientHello) is important for the timely deployment of the
> fix, and with the current draft, that may require fall-back to
> extension-less handshake.
>   
This is not an RI specific issue. TLS already defines a number of
extensions. This fallback policy was implemented not because extension
noncompliant servers were particularly important, but because
implementations needed to have minimal objections for moving forward and
actually using extensions. Today TLS clients regularly use extensions,
so adding one more to allow renegotiation should not be an issue.
>   
> 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.

bob