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

[Andrey Jivsov <[e-mail]>]

On 10/17/2014 06:44 AM, Bodo Moeller wrote:
> Andrey Jivsov <[e-mail] <mailto:[e-mail]>>:
>
>     (On handling of the downgrade to a recent versions of the
>     protocols, i.e. TLS1.3 to 1.2 or TLS1.2 to TLS1.1.)
>
>     The draft -00 asks the server supporting TLS 1.2 to fail the TLS
>     1.1 in some cases, while significant amount of traffic on the
>     Internet goes over TLS 1.0.
>
>
> Right. If both the client and the server *do* support TLS 1.2, we want 
> to ensure that they won't unnecessarily fall back to an earlier 
> protocol version (thus losing the benefits of TLS 1.2). If one of them 
> only supports an earlier protocol version, they'll still be using that 
> one -- TLS_FALLBACK_SCSV doesn't get in the way for that.

Yes, but note that the draft requires servers to fail on TLS 1.1 when 
they were not required to do so before.

This is on the backdrop that the downgrade issue is entirely due to some 
client-specific implementation of the protocol negotiation (the 
fallback) and client's view that TLS 1.1 is secure (as a matter of fact, 
they would currently talk SSL3.0 without any warning).

>
>
>     Today, for example, 
>
>     www.wellsfargo.com <http://www.wellsfargo.com/>, citibank.com
>     <http://citibank.com/>, and bankofamerica.com
>     <http://bankofamerica.com/> don't support TLS 1.1 and
>     mozilla.com <http://mozilla.com/> doesn't support TLS 1.2.
>
>
> Note that this isn't the kind of downgrade that TLS_FALLBACK_SCSV is 
> about.
>
> All of the above sites, and indeed most TLS 1.0 sites on the internet, 
> will properly negotiate the supported protocol version. That is, the 
> client can send a Client Hello advertising support for TLS 1.2, and 
> the server will directly respond with a Server Hello selecting TLS 1.0 
> or TLS 1.1. There's no fallback retry in which the client adjusts its 
> advertised protocol version, and thus no need to send TLS_FALLBACK_SCSV.

The reality of the Internet today is that TLS 1.1 is viewed as 
acceptable. Clients treating TLS 1.1 treating it this way too. The draft 
*requires* to introduce a rejection of TLS 1.1 connection on the server 
when the server detects the downgrade.

My point is that downgrades from TLS1.0 to SSL3.0 is one thing but from 
TLS1.3 to TLS1.2 is another.

>
> Also, even if the client *does* retry with a lower protocol version 
> (TLS 1.1 with TLS_FALLBACK_SCSV, or eventually TLS 1.0 with 
> TLS_FALLBACK_SCSV), such as because the initial handshake failed due 
> to some network glitch, these servers would still accept the new 
> handshakes according to the TLS_FALLBACK_SCSV specification. The spec 
> only requires them to reject Client Hellos with TLS_FALLBACK_SCSV if 
> the advertised protocol version is *lower* than the maximum protocol 
> version supported by the client.

If the server supports TLS1.2 and the server sees TLS1.1+SCSV, the 
server MUST fail with inappropriate_fallback. Isn't this is what section 
3 says?

>
>     I propose the following change that allows to do exactly what rev
>     -00 says, but now enables more tolerant server behaviour.
>
>
> As discussed above, I don't see any problem that this change would 
> address.
>
> The spec intentionally gives exact rules for server-side behavior, 
> allowing the *clients* to fully drive the fallback strategy and 
> determine when it's OK to fall back to an earlier protocol version and 
> when it's not (with no server-side heuristics involved).

Servers are often independent nodes on the Internet. Servers may have 
their own policy regarding when it's appropriate to reject a connection 
and, in general, what are the security implications of the version 
downgrade is.

Today, latest popular browsers will happily connect to a SSL3.0 server 
without any indication to a user.

>
> Bodo
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls