Re: [TLS] One approach to rollback protection

[Martin Rex <[e-mail]>]

Yngve N. Pettersen wrote:
> 
> I am not sure I like this proposal,

I'm very interested in a modified (=interop-improving)
version of this proposal.


> for several reasons:
> 
> - It does not protect against downgrades when connecting to older servers.  
> (rather impossible to do that, of course)

This is no reason for, but also not an issue against it.

> 
> - As noted, it is not protected against a compromised handshake integrity  
> function of an older version, but I guess the handshake version could be  
> changed in such a case.

The existing TLS version negotiation can not protect against that either,
so this is not an issue against the proposal.


> 
> - Forward compatibility. How does a X-year old server that support TLS 1.2  
> understand that that new cipher suite code point is not some new cipher it  
> does not support, but an indication that the client support TLS 1.5? The  
> codepoints would have to not just be predictable, but the codepoints would  
> also have to work for TLS NG using protocol version 4.1. How far ahead do  
> we reserve codepoints, how much of the ciphersuite codepoint space will  
> this eat up? Or do we assume that any TLS 1.2+ server is version and  
> extension tolerant, so TLS 1.2 is the highest version we will ever need to  
> assign a code point for?

I do _not_ want to retire the original TLS version negotiation,
just like to see an alternative "hinting" being standardized to
accomodate a ~10 year transition period to get over TLS version-related
interop problems that exist in today's installed base.

The one thing that I want to see *RETIRED* by this proposal (and all future
updates/version of the TLS protocol) is client_version check on the
RSA premaster secret, because of the bugs in the installed base.

Assuming that the TLS WG produces at most 1 new TLS protocol version
every 2 years, and a 10 year transition period, SCSV values for
TLSv1.0 -> TLSv1.2 -> TLSv1.7 ought to be sufficient.


> 
> - There is no way (at least in the draft) for the client to know that the  
> server understands the SCSV, and processed it correctly. And I can see no  
> possibility expect requiring the server to return a special extension  
> signaling that, similar to the requirement for the Renego SCSV.

The natural place for the server response is ServerHello.server_version,
an element that exists in that PDU even in SSLv3.

Whether the server supports the SCSV is only interesting when the
SCSV is higher than ClientHello.client_version AND the server supports
a protocol version higher than ClientHello.client_version--and that
situation can be easily determined from the ServerHello.server_version
value.


> 
> - How easy would it be for a server or client implementor to get it wrong?

Looking at the varying interpretations of what value the client_version
in RSA premaster secret should be checked against and the age of the
implementations that got this wrong -- EASY, I assume.

But if you take that as a measure, we would have to shut down the IETF.

If there is any hope at all (and I defy to give up that hope), let's
try to be clearer than the existing spec on _all_ details of the
version negotiation ("nanny spec"), and see how it works out.

Compared to rfc5746 renego, this proposal is "simple" on my scorecard.


> 
> - How does the server tell the client that it should always negotiated  
> with the highest supported version when connecting? The server may send a  
> fatal error, but it does not really tell the client what is wrong, or that  
> it should be trying its highest supported version.

The server does not do that.  The idea behind this proposal is that the
client can propose his highest supported (or actually the highest the
client is able and willing to use) TLS protocol version with no ill
side effects on the initial ClientHello.  There are _no_ requirements
to persist any knowledge for future connections.  That is quite similar
to the idea behind the rfc5746 renego SCSV.


Whether and when a TLS client sends version higher than TLSv1.0
in ClientHello.client_version is entirely up to the client.
We are _not_ suggesting to clients to change what they are
currently doing here.

In addition, I do _not_ know which of these ClientHellos is best:

1.  no TLSext, Record.version = 0x03,0x00, ClientHello.version = 0x03,0x00 
2.  no TLSext, Record.version = 0x03,0x00, ClientHello.version = 0x03,0x01 
3.  no TLSext, Record.version = 0x03,0x01, ClientHello.version = 0x03,0x01 
4.  SSL version 2 CLIENT-HELLO.version = 0x03,0x00
5.  SSL version 2 CLIENT-HELLO.version = 0x03,0x01


And would personally not recommend one over the other for clients
that have no reconnect fallback facility.


> 
> IMO The best way to stop version rollbacks occurring is to not allow them,  
> at all. Unfortunately, however, for a time it will still be necessary, for  
> interoperability reasons, to allow fallbacks if the server is intolerant.
> 
> That means finding, or declaring, that certain indications from the  
> server, protected by the handshake hash, means that the server will not  
> willingly require rollback to an older version.


What I am seeing is that an increasing number of TLS clients *IS*
using reconnect fallbacks (all modern Browsers seem to do it),
and the reasons why they need to do them.  TLS version intolerance
and non-conforming RSA premaster secret client_version checks
is a significant problem.  TLS extension intolerance is another,
but for TLS clients that do not send TLS extensions at all,
this does not matter at all.


> 
> This could be either a new extension (which runs up against the extension  
> intolerance problem, and the possibility of an attacker faking the  
> intolerance) or we could use an existing extension to indicate this.

Using a TLS extension uses not only more bytes on the wire and is harder
to implement, it can not be used in any of the 5 cases above, so it
is not a practical alternative.


> 
> As I have mentioned earlier, I think the second option is best, and that I  
> think it already exists in the form of the Renego Indication (RI)  
> Extension.
> 
> My suggestion is that when a client detects that a server have the RI  
> extension, it MUST only use the highest configured version when connecting  
> to that server.  If a server not known to have RI triggers a fallback, and  
> turns out to have RI support, it should immediately start using the  
> highest supported version, and not fall back to an older version if the  
> negotiation fails.


I strongly disagree.  A negotiation that will make the handshake fail
or require two handshakes instead of making the handshake succeed with
the desired result is not a negotiation, but a dirty hack -- even if
it uses elements of protocol PDUs "appropriately" and exactly as the
original design intended. 

TLS extension RI can not be used to repair the TLS version negotiation
which happens on the server side while parsing ClientHello and creating
ServerHello.  For this to work, the client must convey the TLS versions
it supports within ClientHello, in a fashion that upsets close to zero
of the installed base of servers and in a place that exists in all
PDUs to which the existing TLS clients with reconnect fallbacks are
willing to fallback to in case of unexpected connection closures
by the server.  Only in the latter case that band aid will be able
to protect the TLS version negotiation.


-Martin