[secdir] SecDir review of draft-ietf-tls-downgrade-scsv-03

[Yoav Nir <[e-mail]>]

Fear not, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving security requirements and considerations in IETF drafts.  Comments not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

I believe this document is ready for publication with a few minor issues.

The draft describes a mechanism for mitigating the security issue introduced by TLS version fallback mechanisms. TLS servers exist that do not conform to the TLS RFCs with regards to version negotiation. Such servers fail the negotiation even when there is a version of TLS that is supported by both them and the client. To interoperate with such servers, clients often retry the TLS handshake at a lower version. This is sometimes called the "downgrade dance". The downgrade dance allows a version downgrade to happen by either an active attacker or because of a network glitch.  This document introduces an indication in the TLS ClientHello that tells the server that a downgrade dance is in effect, allowing the server to terminate such a connection.

There has been much discussion on the TLS list about the downgrade dance being inherently insecure, and that publishing this document can be perceived as "blessing" this practice. The draft takes no position for or against, but rather assumes that the practice exists, and seeks to prevent such downgrades that are not necessary for connectivity. 

The Security Considerations section has some strange text about omitting the SCSV when "the protocol version given by ClientHello.client_version still provides an acceptable level of protection". This implies that it is appropriate to use a protocol version that does not provide and acceptable level of protection as long as the client sends the SCSV. This is not the case, and this is the reason that several browsers are disabling the downgrade to SSLv3. I realize it is difficult to write text that turns the secure/insecure dichotomy into a trichotomy (secure/so-so secure/insecure), but if we're going to make including the SCSV optional we need such text.

A scenario that bothers me is a server that returns an inappropriate_fallback whenever it receives a TLS_FALLBACK_SCSV with version TLS 1.1, but breaks at TLS 1.2. Such an (admittedly broken) server could potentially send the client into an endless loop of regular and fallback handshake attempts. An attacker could simulate this by RST-ing all TCP connections with TLS 1.2 in ClientHello. I think the draft should warn against doing the regular-fallback-regular cycle more than once. IOW: after receiving the alert, clients MUST NOT perform the downgrade dance on the following connection. Especially, don't implement the following downgrade dance:
 - regular handshake
 - fallback with SCSV
 - regular handshake
 - fallback without SCSV
If anyone ends up feeling the need to implement this, then we've failed miserably.

Nits and minor issues:

Since the client speaks first, it would make sense to have section 4 (Client Behavior) before section 3 (Server Behavior). Section 3 describes how the server responds to this SCSV when the document had only hinted about when the client should send it.

The IANA Considerations are very confusing, saying on the one hand that no values have been allocated, and on the other hand that IANA has assigned 0x56,0x00. Unless the authors are requesting that IANA assign the numbers that they have used in early implementations, it's better to just write "IANA is requested to assign..." and replace the numbers in the rest of the documents with TBDs (if you leave actual numbers and IANA assigns different identifiers, it's likely to be overlooked by the RFC editor).

A few missing articles:
"The fallback SCSV defined in this document is not *a* suitable substitute"
"if *the* TLS implementations also include support for (the) predecessor protocol SSL 3.0"

Yoav