Re: [TLS] Call for acceptance of draft-moeller-tls-downgrade-scsv

[Yoav Nir <[e-mail]>]

On 23/1/14 12:06 PM, Eric Rescorla wrote:
> WG Members,
>
> This message is a call for acceptance of
> http://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01
>
> As a TLS WG item.
>
> Please provide any comments on this action by Feb 7. Because
> there has been only modest discussion of this document, the
> chairs ask people who have already spoken in favor or against
> this document to re-register their opinion (feel free to just say
> +1 or -1 and point back to the archives.)

+0.5

I'm not opposed to this document, but we should be realistic as to what 
this solution can accomplish.

This extension (I use this term in the sense of protocol extension, not 
TLS ClientHello Extension) will not protect the client or the server 
from a TLS proxy. TLS proxies that do not support high versions of TLS 
will negotiate both the client and the server down to TLS 1.0, and will 
not forward the SCSV.

Also, older servers will not recognize the SCSV and ignore it. So to 
have this extension add any value, all of the following much be true:
  - an updated server
  - an updated client
  - Something that causes the negotiation to fail. This something could 
be the client, the server, or something in between. The goal of this 
extension is to catch the something in the middle.

So presumably, the server blocks the connection, or returns a 
poorly-protected error page whenever it gets the SCSV. But this could be 
caused by a MitM that drops negotiations that have a too-high TLS 
version, or by client bugs or by server bugs. Broadly speaking, I think 
there are four failure scenarios:
  1. either the (updated) client or the (updated) server have bugs that 
caused the TLS 1.2 handshake to fail.
  2. The (updated) client has a bug causing it to send the SCSV even 
though no downgrade happened
  3. An attacker is on-path and is dropping TLS 1.2 because it can break 
TLS 1.2.
  4. An older firewall is dropping the TLS 1.2 connections, because they 
fail some sanity check. (that all TLS records have 3.0 or 3.1 in the 
record header)

So the extension makes sense if #3 is the likely scenario for failure. 
Any failure for the other reasons is kind of "collateral damage" that I 
don't think is justified in a world where TLS 1.0 is not considered so 
terrible as to disable it entirely. So I guess we need to hear some 
real-world experience about where most such failures would come from.  
Of course, we don't have any data *now* about buggy updated servers, so 
we'd have to guess how many and what kind of bugs are going to be 
present in not-yet-written code.

Yoav