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

[Andrey Jivsov <[e-mail]>]

On 10/18/2014 05:08 AM, Bodo Moeller wrote:
> Andrey Jivsov <[e-mail] <mailto:[e-mail]>>:
>
>     The reality of the Internet today is that TLS 1.1 is viewed as
>     acceptable. Clients treating TLS 1.1 treating it this way too. The
>     draft *requires* to introduce a rejection of TLS 1.1 connection on
>     the server when the server detects the downgrade.
>
>
> 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?

Please allow me to suggest that the opposite might be equally viable: a 
client MUST include TLS_FALLBACK_SCSV (with any downgraded negotiation) 
and server SHOULD respond with an inappropriate_fallback alert.

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.

>     My point is that downgrades from TLS1.0 to SSL3.0 is one thing but
>     from TLS1.3 to TLS1.2 is another.
>
>
> You appear to be saying that, carefully weighing the case, a silent 
> fallback to TLS 1.2 can be acceptable. I don't disagree: the spec 
> takes this into account, it's just that it leaves it to the *client* 
> to make this decision, without further *server*-side heuristics 
> interfering with it,.

Thank you for considering this issue, Bodo.
>
> (I think this makes sense because it's the client that decides whether 
> to do fallback retries in the first place. For clients that don't set 
> TLS_FALLBACK_SCSV at all, for example, any server-side enabled 
> protocol version can be negotiated anyway -- the server can't avoid 
> using old versions with such clients other than by disabling them 
> entirely.)

... Yet the server has the content.

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

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.

Is this intended for clients that allow end-users to tweak how SHOULD is 
interpreted?

If we have protocol dance on the client (heuristic #1) and SHOULD 
include TLS_FALLBACK_SCSV  (heuristic #2), this may complicate 
diagnosing this on the server.

I would say (regardless of the server SHOULD or MUST), that one is free 
not to implement the draft on the client. If he does, he MUST send the 
TLS_FALLBACK_SCSV on the downgrade.