Re: [TLS] The TLS_FALLBACK_SCSV time bomb (was: Re: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00)

[Bodo Moeller <[e-mail]>]

Hubert Kario <[e-mail]>:


> [...] I think the only thing we can do to prevent
> that is to be explicit in the document:
>
> "The client MUST NOT advertise TLS_FALLBACK_SCSV if it initiates connection
> with the highest protocol version it supports."


Right, I think stating this explicitly in the spec is probably the right
thing to do (of course this has been the intended behavior all along).
Thanks.

(Arguably the OpenSSL API is too fragile, and SSL_MODE_SEND_FALLBACK_SCSV
should be ignored in this case. So clarifying that in the spec is not the
*only* thing we can do to prevent this.

Also, if a few HTTPS servers log information such as the User-Agent header
if they see a client hello advertising TLS 1.2 with TLS_FALLBACK_SCSV, that
could be used to track down any clients that still manage to get it wrong.
That seems more practical than using clients to find version-intolerant
servers, because for that you'd have to send TLS 1.3 or TLS 1.4 client
hellos before these protocols actually exist, and then wouldn't quite know
what to do in case the server actually chooses one of these versions.)

While I don't see any way to completely avoid interoperability failures in
the presence of potential bugs, I think this failure scenario (buggy
clients potentially sending TLS_FALLBACK_SCSV in every handshake) really
isn't as bad as the alternatives -- such as strictly expecting servers to
be version-tolerant for protocol versions they've never been tested with.
There's always *some* way how buggy implementations could break
interoperability.

Bodo