Re: [TLS] SCSV versioning

[Bodo Moeller <[e-mail]>]

Dan Wing <[e-mail]>:

I recently became aware that Microsoft IE won't implement SCSV.  Near as I
> can tell, this is the main concern [...]:
>

> One of the developers pointed out that the TLS_FALLBACK_SCSV feature has
> a significant downside-- because it doesn't convey any specific version
> information, it becomes a general "never fall back" signal. The problem is
> that such signals are too broad; fallbacks were only ever introduced
> because servers often use TLS stacks with implementation bugs. Any "don't
> fallback" signal sent by such a server will be very bad for compat.
>

I haven't seen this particular complaint before, and also can't quite make
sense of it. TLS_FALLBACK_SCSV is a signal sent by the client, not by the
server as that statement implies (and of course, IE acts as a client). The
specification (draft-ietf-tls-downgrade-scsv-05) says that clients SHOULD
send TLS_FALLBACK_SCSV in fallback handshakes, and that servers MUST react
to it in a specific way. This expressly gives clients some latitude,
allowing trade-offs that may be needed for the sake of compatibility.
(Also, if a client never does a fallback handshake, there's no reason to
send TLS_FALLBACK_SCSV in the first place.)

A related (in a Chinese-whispers way, anyway) complaint that I *have* seen
is the one I've addressed in
http://www.ietf.org/mail-archive/web/tls/current/msg14848.html.  (See also
https://datatracker.ietf.org/doc/draft-ietf-tls-downgrade-scsv/shepherdwriteup/
.)

Bodo