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

[Joseph Salowey <[e-mail]>]

On Mon, Jan 19, 2015 at 3:15 AM, Bodo Moeller <[e-mail]> 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.)
>
>
> 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."
>>
>
> 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:
>>> "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)
>>
>
> Which is why I'll need Adam for these decisions :-)
>
> Bodo
>
>
>