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

[Yoav Nir <[e-mail]>]

> On Jan 18, 2015, at 10:56 PM, Bodo Moeller <[e-mail]> wrote:
> 
> Thanks for your comments, Yoav!
> 
>  
> 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.
> 
> Could you make a concrete (if rough) suggestion for what you'd like to see in the document?  Note that the text that you cite above was essentially contributed by one of the WG chairs :-) [*]  Personally, I don't see a need for additional text because I think that the document already makes it quite clear that the reason why a client might tolerate an otherwise unacceptable level of security when sending the SCSV is as a last resort for connections to legacy servers.
> 
> Regarding your statement that "this is the reason that several browsers are disabling the downgrade to SSLv3", I don't agree.  If TLS_FALLBACK_SCSV was already widely deployed in servers, browser vendors would have had a much less pressuring need to disable the downgrade to SSL 3.0 entirely -- with the SCSV, SSL 3.0 would have been exclusively about hopeless legacy servers anyway,

I could ask what is so bad then with downgrade attacks, since it’s apparently SSLv3 is good enough for the client and good enough for the server. What do we care then if we get there through a software bug, an active attack or just misconfiguration? We still get an acceptable level of security, or we wouldn’t support it.

I’m not really making this argument, because I realize that the realities of deploying protocols and products is such that you sometimes want to assume some level of risk when connecting to a server. The text in the security considerations is describing a less secure practice than in the rest of the document. It’s saying that it’s OK to allow the downgrade to some TLS versions that are still considered secure enough. So I would start with the justification. Something like:

“Adding anything to a TLS handshake runs the risk of causing interoperability problems with non-compliant implementations. Such behavior is even more likely in servers that did not implement version negotiation properly. In order to avoid unnecessary connectivity problems, clients MAY omit the TLS_FALLBACK_SCSV when downgrading to a version of TLS that is still considered secure.”

BTW: since the working group has an active document deprecating SSLv3 (https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00 <https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00>), you might consider removing the "permission" to downgrade to SSLv3.


> 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.
> 
> The problem is, the alert is not authenticated.  (We'd have to complete the handshake to authenticate it.)  So a "MUST NOT" can't be right: if a browser users tries to access a web page a second time after the above failure, it's appropriate for the client to perform the entire downgrade dance again if needed.  Implementors shouldn't go into infinite reconnect loops, but I don't think there's anything special here about TLS_FALLBACK_SCSV.

I’m fine with trying the whole thing again if the user refreshes the browser. What I think you should warn about is an automatic endless loop. When the TLS 1.2 connection gets a RST, the browser automatically retries at a lower version, no user interaction required. If that leads to an inappropriate_fallback alert, the client “should then retry with the highest version it supports”. This makes it seem that a particularly broken server could have the client retrying handshakes indefinitely, so to that sentence, I would add “and not attempt downgrades if that handshake should fail."

> 
>  
> 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.
> 
> My rationale for describing server behavior before client behavior was that I think this makes it easier to read the document, given that server behavior follows simple, concrete, and strict rules. After you've read those in the Server Behavior section, I believe it will be much easier to make sense of the (more complex) section on Client Behavior.  If you don't know what server behavior TLS_FALLBACK_SCSV triggers, my fear is that the Client Behavior section will seem very esoteric, abstract, and nebulous.

OK. 

> 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).
> 
> Right, the point is specifically to use the numbers that have been used in existing implementations.  Isn't the "TO BE REMOVED" note rather clear about that?  In any case, the contradictive part obviously isn't meant to go into the final document -- the current form is meant to show the intended final document text while also making it clear that IANA hasn't yet assigned anything.

Sure. IANA will weigh in on your draft, as they do on all documents, so that’s between you, them and the designated expert.

> 
> 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"
> 
> I don't think either of these is technically necessary, but I'l entirely leave the decision about these articles to my co-author :-)  (In the first case, by the way, it's again language contributed by said WG chair. [*])

As a non-native English speaker, I’ll leave the grammar corrections to you and the RFC editor (although some ADs tend to engage in that as well)

Yoav