[TLS] Avoiding first use of RI in ClientHello

[Eric Rescorla <[e-mail]>]

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.

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.


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).  However, the server treats this
EXACTLY as if the client had offered an empty RI extension, and
responds with its own RI extension (or if it doesn't implement the
full extension framework, just adds a known byte string to the end of
the ServerHello). In other words:


Client                                          Server
------------------------------------------------------
ClientHello + TLS_RENEGO_PROTECTION_REQUEST -> 
                             <- ServerHello + Empty RI


At this point, the client now knows that the server supports secure
renegotiation and can simply send RI in any renegotiation handshake
(and if the client doesn't implement the full extensions framework, it
could just add a known byte string to the end of the ClientHello,
without requiring full extension support). Note that this is
reminiscent of the SSLv2->SSLv3 transition where clients would
initially offer backward compatibility handshakes but once they knew
the server was SSLv3-capable would offer the new ClientHello.


What about 5246 and unsolicited extensions?
As far as I can tell, the major argument against using extensions
for S->C signalling is the 5246 prohibition against the server providing
unsolicited extensions. However, that was clearly intended to prevent
the server from sending extensions the client didn't expect and
that's not the case here. Moreover, we're updating 5246 so we can relax
the restriction for this extension (though I would think not in general).


What about not putting the verify data in the extension?
I think that issue is separable from the question of how we signal
support, so would like to deal with it separately. (It seems this
won't make any difference for the bigger questions like can deploying
the fix break things that currently work, or whether you can implement
the fix purely inside the TLS library)


What about SSLv3?
Obviously, the ClientHello is compatible with SSLv3.  (and the magic
cipher suite can be offered even in SSLv2 backward compatible
hello---ugh!). Although SSLv3 does not have the TLS extension
framework, we could also specify that the server (once it sees the
magic cipher suite indicating the client supports this draft) just
appends the relevant fixed-length byte string to the end of the
ServerHello.


What do people think about this approach?

-Ekr

[*] I didn't invent this approach, I'm just reproposing it to try to focus
discussion.