Re: [TLS] One approach to rollback protection

["Yngve N. Pettersen" <[e-mail]>]

Hi,

I am not sure I like this proposal, for several reasons:

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

- 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.

- 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?

- 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.

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

- 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.

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.

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.

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.

Sure, this is a bit of a hack, too, but it is one that can be deployed  
quickly (60+% of servers already support RI) without any further server  
updates, it need only be implemented client side, and the current server  
failure rate is less than 0.1% of all tested servers when signalling TLS  
1.1, TLS 1.2, or extensions (which is the major part of the failures),  
totaling only a few hundred sites in my sample (and I think these will be  
straightened out in short order once they start failing in all clients).

Any server that would implement a check for these SCSVs would (or should)  
also already:

   - Be extension tolerant
   - Be version tolerant
   - Implement the RI extension

If the RI is used as an indication of tolerance then the only way an  
attacker would be able to force a downgrade would be if he is able to fake  
the Finished message, a problem that this document admits also exists for  
the SCSV suggestion.

I therefore think using RI as an indicator will be a better solution  
(there is no perfect solution, unfortunately)

On Tue, 27 Sep 2011 01:44:18 +0200, Eric Rescorla <[e-mail]> wrote:

> I've been doing some thinking about how to prevent rollback to
> TLS 1.0/SSLv3 from TLS 1.1-capable agents.
>
> Since there's very little deployment of TLS 1.1+, basically anything
> we do now will roll out more or less in parallel with TLS 1.1 deployment,
> as long as it's backward compatible.The obvious technique here is to
> stuff the relevant indicator in the cipher suites list, since we know  
> that
> servers ignore unknown entries there.
>
> I've taken an initial crack at a draft for this:
> http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt
>
> -Ekr
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls


-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************