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

[Daniel Kahn Gillmor <[e-mail]>]

On 10/27/2014 02:58 PM, Andrey Jivsov wrote:

> I think that these fallback heuristics will contain false-positives. My
> thought was that if the server has SHOULD fail, it could do something
> like never fail on TLS1.1 and higher (or TLS1.2 when TLS1.3 is out).
> Otherwise one must accept that servers implementing TLS_FALLBACK_SCSV
> will contribute to higher number of failed handshakes.

The failed handshakes associated with false positive fallback behavior
are from network glitches, right?  not from poorly-implemented or
unmaintained servers.

in the face of a network glitch, user agents have three options (browser
behavior in parens):

 0) report the connection failure up the stack (browsers: show the user
the "try again button")

 1) automatically try the connection again, same as last time

 2) try the connection again with a fallback handshake



in the false positive cases that we're discussing here, (1) is probably
the best option.  doing (2) leads directly to choosing a degraded
ciphersuite.

including the SCSV with (2) gives the client an inappropriate_fallback
alert, which they can use to recognize the false positive situation and
do (1) instead.

	--dkg