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

[Adam Langley <[e-mail]>]

On Fri, Sep 26, 2014 at 10:44 AM, Andrei Popov
<[e-mail]> wrote:
> This I-D currently forces clients to do sequential fallbacks, without skipping versions: TLS1.3->TLS1.2->TLS1.1->TLS1.0 will work, but e.g. TLS1.3->TLS1.2->TLS1.0 won't. Clients may want to skip protocol versions in the fallback sequence to reduce latency. Clients may also need to disable arbitrary protocol versions for security reasons.
>
> I see two ways to fix this in the draft:
> 1. Use a TLS extension instead of an SCSV. In the extension, the client could indicate the previously attempted protocol version. The problem with this is that SSL3 ClientHellos are not supposed to have extensions, but we'd like to secure fallbacks to SSL3.
> 2. Use one SCSV value per TLS & SSL protocol version. The client includes the SCSV indicating the previously attempted protocol version. The drawback here is that this creates multiple SCSVs:).
>
> If this problem is not solved, then clients will have no choice but to avoid sending the SCSV when skipping protocol versions, e.g.: TLS1.3(no SCSV)->TLS1.2(with SCSV)->TLS1.0(no SCSV). Which (at least partially) defeats the purpose of the I-D.

We've had the design of an SCSV-per-version before and it didn't
really go anywhere. (There is, at least, ekr's draft[1].)

Yes, you have to step down every version. But stepping down is a good
idea because you want to lose as few features as possible. If you drop
right down to SSLv3 then you loose ECDHE and so on.

It's more latency, but only for the case of very old, broken servers. So be it.

[1] https://github.com/ekr/ietf-drafts/blob/master/draft-rescorla-tls-version-cs.txt


Cheers

AGL

-- 
Adam Langley [e-mail] https://www.imperialviolet.org