Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00

[Florian Weimer <[e-mail]>]

On 10/15/2014 06:13 PM, Salz, Rich wrote:
> It retried because there was no way to indicate "let me try again with older version"  Now there is a way to indicate that this is happening.  Servers who support better protocols will reject the connection because the browser might be unwittingly giving up valuable security properties.  Servers who don't support better protocols will complete the handshake.

Sorry, but please review the Mozilla bug and re-read what I wrote.  I 
have a feeling that we both are talking about different things.

I'm concerned that a straightforward implementation of this new SCSV in 
Firefox will introduce user-visible connection failures when the 
downgrade is caused by a (likely spurious) networking event.  It's true 
that this network failure could be introduced deliberately by an on-path 
attacker (but even the SCSV design assumes that's rare*).  It's also 
true that an attacker can disguise most attacks as networking anomalies. 
  But it's unfortunate that this SCSV has such a broad area of ambiguity 
which does not help with browser UI design at all.

I understand that the ship has sailed on this one, and that we cannot 
change the protocol anymore.  So publishing the RFC seems unavoidable at 
this point, if only to ensure the codepoint reservations stick.


*) Deploying an SCSV-enabled browser to users on an intercepting network 
will largely knock these users off the net (assuming that SCSV support 
is widely deployed in public-facing TLS termination), so such attacks 
are hopefully very isolated, or else it's not possible to deploy this 
feature in browsers.

-- 
Florian Weimer / Red Hat Product Security