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

[Bodo Moeller <[e-mail]>]

Andrey Jivsov <[e-mail]>:

> According to the draft, this server-side rejection is REQUIRED *if the
> client sent TLS_FALLBACK_SCSV to request it*. For the client, however, it
> is merely RECOMMENDED to send TLS_FALLBACK_SCSV in all fallback retries.
>
>

> Thinking more about it, there are two issues I see with the above: "smart
> client / dumb server" model and SHOULD for the client use of
> TLS_FALLBACK_SCSV.
>
> What was the rationale for the dumb server / smart client design?
>

The client is the one making fallback decisions anyway. Mixing that with
server-side heuristics makes it less clear what's going on (then, neither
the client nor the server could fully enforce its preferences).



> Example. Most often the servers are the custodians of the information /
> content. Servers are managed by professionals and are properly maintained.
> A server security policy might require TLS 1.1 to access the content that
> it serves. When such a server receives a ClientHello with TLS 1.0, it might
> proceed with a handshake, but display an HTML page explaining that access
> was denied due to low security, perhaps adding how to remedy the problem.
> In the end this is more secure: the same result of denying access to
> information, but with a more informative message. Neither the server nor
> the client implementations may find it appealing to code a special warning
> message specifically to flag MiT downgrade attack when TLS_FALLBACK_SCSV is
> used (e.g. to avoid false-positives), however, the server may include some
> of this information on the above-mentioned page as well, or choose to send
> inappropriate_fallback alert.
>

Well, if you think this might really happen, the scenario only confirms
that the server-side MUST is exactly right ... because if the server
includes a warning message in content it serves rather than entirely
rejecting the connection, that's well-intentioned but dangerous misbehavior
we should rather prevent. (If the server allows the downgraded handshake to
complete, the client will send secrets such as HTTP cookies even though
they may not be adequately protected.)


Currently the client has SHOULD for TLS_FALLBACK_SCSV. Why is this one not
> MUST (regardless of the server MUST or SHOULD)?
>

When you start experimental use of TLS 1.3, incompatibilities between
implementations might result in handshake failures, and silently falling
back to TLS 1.2 (without the SCSV!) could then make sense -- hence the
SHOULD (rather than MUST) for the client. (To fix interoperability,
alternatively you'd completely disable TLS 1.3 in the client, and the
fallback isn't worse than that.)



> This SHOULD for the client means that the client that implements the draft
> will use some logic to switch between cases:
> a) as if doesn't implement the draft
> b) client sends TLS_FALLBACK_SCSV with any downgraded negotiation
>
> If client does a), perhaps by interpreting network errors, POODLE
> continues to live.
>

It's a SHOULD, not MAY. I don't think omitting the SCSV when falling back
to SSL 3.0 is reasonable. (See also the draft-ietf-tls-downgrade-scsv-00
Security Considerations.)

Bodo