Re: [TLS] One approach to rollback protection

[Juho Vähä-Herttua <[e-mail]>]

On Sep 27, 2011, at 4:39 AM, Marsh Ray wrote:
> I agree that the current semantics are starting to feel a bit silly. Support for TLS 1.2 also implies a willingness to speak SSLv3?
> Are we expecting to continue this forever?

How come support for TLS 1.2 also implies a willingness to speak SSLv3? I don't see that in the specification.

> On 09/26/2011 08:14 PM, Eric Rescorla wrote:
> > In an environment where the client could indicate any combination of
> > versions, the impact of implementing TLS 1.2 only would be that a
> > server which did not support TLS 1.2 would generate an error instead
> > of a ClientHello. [ServerHello?]
> >
> > Since servers are supposed to select the highest common version, I'm
> > not sure I see serious difference between these two.
> 
> The difference is that somebody will look at Wireshark and instead of seeing random disconnects and thinking they're the subject of some low-level DoS attack, they'll see a bright yellow line that reads:
> "TLS Alert: Endpoints support no common protocol version."

There is already a protocol_version alert, which is supposed to have exactly this meaning. If the client sends a lower version than the lowest supported server version in ClientHello, server replies with protocol_version alert. If the server sends a lower version than the lowest supported client version in ServerHello, client replies with protocol_version alert. Only problem here is that the version negotiation is broken in implementations, not that it doesn't work in theory...

The problem I believe Martin was trying to point out is a hypothetical case where a client for example supports TLS 1.1, TLS 1.2 and SSLv3 for backwards compatibility, but not TLS 1.0. When it connects to a server which supports SSLv3 and TLS 1.0 only, the server will most likely reply with TLS 1.0 in ServerHello. Now the client can only reply with protocol_version to indicate no common protocol version was supported, even though in fact SSLv3 handshake would have succeeded. Only way to fix this properly would be to explicitly list all supported versions in the ClientHello.

The suggestion brought up by Eric could make this possibly with only slight modifications, but then it would effectively override the current version negotiation. I can easily see a scenario where all implementations send TLS 1.0 in ClientHello and send all higher supported versions as cipher suites. That would be ugly, and I hate abusing the cipher suites for renegotiation and now this, but I have to admit it would solve a lot of problems...

About the current proposal by Eric I have to agree with Martin, it is a hack that only increases handshake failures without helping in any way with the current version negotiation problems. Implementing a proposal like that doesn't make much sense to me.


Juho