Re: [TLS] Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard

[Brian Smith <[e-mail]>]

Martin Rex <[e-mail]> wrote:
> Permitting the server to continue the TLS handshake with
> ServerHello.server_version = (ClientHello.client_version +1)
>
> This would be an extremely small change, but a *HUGE* improvement to this
> proposal and make TLS handshakes _succeed_, i.e. promote interop.

This doesn't work. Consider this example of how your suggestion would work:

Client and server both support TLS 1.2.

Client attempts TLS 1.2, receives RST.
Client attempts TLS 1.1 w/ downgrade SCSV, receives RST.
Client attempts TLS 1.0 w/ downgrade SCSV, receives TLS 1.1 ServerHello.

This results in a downgrade from TLS 1.2 to TLS 1.1.

> Should a TLS client be unsatisfied with the properties of the resulting
> TLS session, that client could still decide attempting a new/different
> handshake by proposing additional features in ClientHello (that should
> have never been absent from ClientHello in the first place).

I think at this point browsers are only "satisfied" when the
connection is TLS 1.2 using an AEAD cipher suite, but they still feel
the need to support servers that only support worse crypto. So, this
part of the idea doesn't work either.

> It's not that suggestions to improvement to this proposal haven't been
> made.  It's really disappointing to see this go _through_ the TLS WG
> and not seeing any improvement whatsoever, and then going straight
> to asking for rubber-stamping it.

I don't think that the characterization of "rubber-stamping" is
accurate or helpful for moving the discussion forward.

I DO think it would be useful for the IETF to wait ~8 weeks to see the
results of Firefox's experiment in disabling the non-secure fallback,
and to see the results of studies of TLS 1.3 intolerance with
ClientHello messages with different record-level version numbers. If
it turns out to be reasonable for web browsers to stop doing the
non-secure fallback, then it really would be bad policy for IETF to
make the downgrade a proposed standard, because the downgrade SCSV
will always be limited in effectiveness by the fact that a huge number
of servers will not deploy the downgrade SCSV mechanism any time soon.
Still, it's not clear yet that web browsers can reasonably stop doing
the non-secure fallback, so I think it makes sense to have the
downgrade SCSV mechanism ready as insurance.

Cheers,
Brian