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

From: Yoav Nir <[email-masked]>
Date: Sun, 18 Jan 2015 19:10:12 +0200

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

---

From: Bodo Moeller <[email-masked]>
Date: Sun, 18 Jan 2015 21:56:09 +0100

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,

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.

> 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.

> 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.

> "if *the* TLS implementations also include support for (the) predecessor

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. [*])

Bodo

[*]  No intent to shift any blame: I think the current text is fine, or I
wouldn't have used it.  However, this lets you know who's in a special
position to convince me to change that wording.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 19 Jan 2015 09:11:28 +0200

> On Jan 18, 2015, at 10:56 PM, Bodo Moeller <[email-masked]> wrote:
> 
> 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."

> 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. 

> 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.

> 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

---

From: Joseph Salowey <[email-masked]>
Date: Mon, 19 Jan 2015 10:47:51 -0800

On Mon, Jan 19, 2015 at 3:15 AM, Bodo Moeller <[email-masked]> wrote:

> 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.
>>
>
> It's certainly not good enough in general, but if it's the best you can
> get with a particular server, you might prefer it over not being able to
> use any kind of encryption (however weak) at all, and in particular you
> might prefer it over a connection failure.  If you browse the web, you
> don't necessarily always care about HTTPS for all servers -- and if you
> don't really trust a particular HTTPS server and don't exchange any secrets
> (such as passwords) with it, even ROT13 might be "acceptable" for
> connections to that specific server because the connection could just as
> well be using plaintext HTTP.  Assuming that all servers that you actually
> care about have been updated to support a better protocol version, you'd
> want the handshake to make sure that connections to any of these servers
> actually use that protocol.
>
> So my point is that there isn't necessarily a single minimum security
> level to be required for *all* connections.  For many applications, there
> may be one (and you'd probably disable plaintext connections entirely for
> these), but in general, draft-ietf-tls-downgrade-scsv-03 is about helping
> you achieve the best security level that is possible with a particular
> server.
>
> I don't mean to imply that SSL 3.0 shouldn't be disallowed entirely, but
> consider TLS 1.0 instead.  So maybe we don't know a fatal weakness in TLS
> 1.0 at this time, and thus TLS 1.0 is probably still "acceptable" for
> connections to servers that don't support anything better.  However, if the
> server speaks TLS 1.2 (or, in the future, TLS 1.3), we'd want to insist on
> using the newer protocol version -- so TLS 1.0 is "unacceptable" for these
> connections.  We don't necessarily yet know all the concrete reasons to
> avoid the earlier protocol version.  Whether you should disallow TLS 1.0
> entirely because it's now an obsolete protocol is simply not a question
> that draft-ietf-tls-downgrade-scsv-03 is about.
>
> So you can have a long and complicated discussion about which protocol
> version is acceptable or unacceptable when. The question is, what of that
> belongs into draft-ietf-tls-downgrade-scsv-03 and what would rather be
> distracting?
>
> Currently the document mentions that downgraded connections can be "a
> useful last resort for connections to actual legacy servers" and that
> "unnecessary protocol downgrades are undesirable".  I'm hoping that this
> will be enough, but maybe it's possible to write something that will help
> make things clearer without creating additional confusion.  What would you
> think of an additional sentence that simply points out that implementations
> will typically want to disallow certain protocol variants entirely (even
> with TLS_FALLBACK_SCSV), but that any details of this are out of scope of
> the document?
>
>
>

[Joe] Just to clarify, my intention with this text was to warn against
eliminating the SCSV and therefore the downgrade protection it provides. My
intention was not to say that it is OK to use a version that you normally
would not allow if you include the SCSV. I'd be OK with additional text
that says you want to disallow unacceptable protocol variants entirely even
with TLS_FALLBACK_SCSV.   I'm open to other suggestions for improving the
text.

>
>
>> 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.”
>>
>
> This doesn't really cover all reasons why you might want to omit
> TLS_FALLBACK_SCSV from some downgraded handshakes.  I'm not too worried
> about TLS_FALLBACK_SCSV being mishandled by non-compliant implementations.
> I'm more worried about a TLS 1.2 + TLS 1.3 server rejecting a TLS 1.2
> handshake with TLS_FALLBACK_SCSV *because* it complies with the
> specification, after an earlier TLS 1.3 handshake attempt has failed
> because the server or the client (or both) have bugs in their TLS 1.3 code
> (or because they implement incompatible I-Ds for TLS 1.3).
>
>
>
>> BTW: since the working group has an active document deprecating SSLv3 (
>> https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00), you
>> might consider removing the "permission" to downgrade to SSLv3.
>>
>
> Hm, draft-ietf-tls-downgrade-scsv-03 doesn't intend to "allow" any
> particular downgrade.  What it's telling clients, rather, is "If you must
> downgrade, then at least send TLS_FALLBACK_SCSV".  (Of course, any
> instructions concerning SSL 3.0 are moot as soon as no one downgrades to
> SSL 3.0, but we need to avoid any risk of ending up with client
> implementations that include TLS_FALLBACK_SCSV in any *TLS* fallbacks but
> ultimately fall back to SSL 3.0 without the SCSV -- so we can't just
> pretend that SSL 3.0 doesn't exist.)
>
>
>> 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
>> 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."
>>
>
> The full sentence that you're referring to is "Thus, if a client intends
> to use retries to work around network glitches, it should then retry with
> the highest version it supports."  This isn't meant to instruct clients to
> retry, it just tells them how to do any retries.  Apart from that aspect,
> it's not specific to TLS_FALLBACK_SCSV, and I don't want to add unwarranted
> regulation of implementation details.  If a client would normally retry
> multiple times to work around network glitches, that's still just as
> acceptable (or unacceptable) with TLS_FALLBACK_SCSV, even if it means going
> through the downgrade dance multiple times automatically.  If a client
> would normally retry in an infinite loop (hopefully, with exponential
> backoff), that's just as acceptable (or unacceptable) with
> TLS_FALLBACK_SCSV.  We may have opinions on any of these design choices,
> but those don't really belong into draft-ietf-tls-downgrade-scsv-03.
>
> Maybe that sentence can be made clearer, though.  How about rewriting that
> paragraph as follows (the first sentence is unchanged)?
>
> "Fallback retries could be caused by events such as network glitches, and
> a client including TLS_FALLBACK_SCSV in ClientHello.cipher_suites may
> receive an inappropriate_fallback alert in response, indicating that the
> server supports a higher protocol version. Thus, if a client intends to use
> retries to work around network glitches, the next retry after an
> inappropriate_fallback alert should use the highest version that the client
> supports."
>
>
>
> A few missing articles:
>> 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)
>>
>
> Which is why I'll need Adam for these decisions :-)
>
> Bodo
>
>
>

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 19 Jan 2015 20:56:10 +0100

>> leave the decision about these articles to my co-author :-)
>>
>>
I've just received Russ Housley's Gen-ART review, in which he also asked to
change "is not suitable substitute" into "is not a suitable substitute"; so
I'll do that.

Bodo