Subject: [TLS] Cipher suite values to indicate TLS capability

From: Adam Langley <[email-masked]>
Date: Tue, 5 Jun 2012 16:39:46 -0400

(I'm floating this idea before implementing it.)

All major HTTPS clients (and possibly other TLS clients too) implement
fallback in order to workaround buggy networks and buggy servers. If a
handshake fails with any one of a number of spoofable errors, the
client will retry with more conservative options enabled. Eventually
the client will retry the connection with vanilla SSLv3.

There is no indication that the world is going to improve to the point
where we can remove this fallback any time soon. About 1% of
connections still need to do it.

However, with the downgrade to SSLv3 we loose an important security
feature: ECDHE. As SSLv3 doesn't support ECDHE, an attacker can cause
the key-agreement algorithm to switch from ECDHE-RSA to RSA (this
affects Google at least). On the server side, we're not going to
switch on multiplicative DH at a strength similar to P-256 because of
the DoS impact so clients will loose forward security. Also, with a
plain RSA ciphersuite, it's possible for an attacker with the server's
private key to decrypt the pre-master secret and assume control of a
TLS connection. This means that the attacker will be authenticated
with any client-certificate used, something that isn't possible with
forward secure ciphersuites.

So I'd like to introduce TLS_CAPABLE_SCSV (0x00fe) in SSLv3
handshakes. TLS_EMPTY_RENEGOTIATION_INFO_SCSV has shown that we can
deploy new ciphersuites for SSLv3 and the semantics of
TLS_CAPABLE_SCSV would be that servers would reject any SSLv3
handshakes that included this ciphersuite with a fatal error. (Thus
TLS_CAPABLE_SCSV would only be included when the handshake was the
result of a fallback.)

That begs the question of whether we should introduce
TLS_1_1_CAPABLE_SCSV and TLS_1_2_CAPABLE_SCSV. At the moment we don't
have any critical security benefits in TLS 1.1 or 1.2 that an attacker
could deny us by forcing a fallback, therefore I don't see a pressing
need for them at the moment.

If there aren't any solid objections, I'll write up a draft.

Cheers

AGL

---

From: Adam Langley <[email-masked]>
Date: Tue, 5 Jun 2012 17:23:11 -0400

wtc pointed out
http://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-version-cs.txt
from last year. I didn't build on that because it didn't seem to go
anywhere, sadly.

Although it's worth noting that my previous comment:

"This doesn't really make the deployment of new TLS versions that much
easier. The client would still have to try 1.2, 1.1, 1.0 etc. What
would be helpful is if the server, seeing a TLS 1.2 SCSV, treated the
client as if it has advertised 1.2."

Has turned out to be false. We're now aware of networks which filter
on the version in the returned ServerHello.

Yngve's point about just using the renegotiation extension as an
indication, client-side, that we shouldn't have done a fallback is
still a possibility.

Cheers

AGL

---

From: Geoffrey Keating <[email-masked]>
Date: 05 Jun 2012 16:16:31 -0700

> forward secure ciphersuites.

Could you simply send the ECDHE values anyway?  If the remote end
accepts them, you can reasonably be sure you're under a downgrade
attack (but see below).

> TLS_CAPABLE_SCSV would only be included when the handshake was the

One problem with this proposal is that in practice it isn't really
indicating 'TLS 1.0 capable'.  A system might actually support TLS
1.0, but not extensions, or it might have trouble parsing the
particular EC extensions you sent, or some other extension, or it
might not like the negotiated cipher suite, or the total number of
proposed cipher suites, or the compression algorithm.  Or it could
have mysteriously failed (once) for reasons unconnected to the TLS
negotiation.

So, I don't think this is a good candidate for standardization.  You'd
need to come up with a 'preferred' client hello, and then have the
cipher suite value mean very specifically that the preferred client
hello should have been accepted...

---

From: Adam Langley <[email-masked]>
Date: Tue, 5 Jun 2012 19:35:31 -0400

> accepts them, you can reasonably be sure you're under a downgrade

We would need to send both the ECDHE ciphersuites and the extensions
outlining the acceptable curves and point formats. Adding all that
would reasonably cause SSLv3-only servers to reject the ClientHello.

> have mysteriously failed (once) for reasons unconnected to the TLS

Well, all of those save the last are failures to implement TLS
correctly, so then it's not TLS capable :)

(As for transient network errors: these happen but fallback isn't
intended to work around them. Whatever reconnection logic we might
have is orthogonal to this and would be common between HTTP and HTTPS
connections. We don't actually do fallback from TLS to SSLv3 for TCP
level errors in Chrome.)

Obviously this is a sacrifice of elegance on the alter of practical
need. What the SCSV effectively says is that the server implements TLS
to a level that was common at the time that servers started to be
patched with SCSV support. That isn't perfect, or even good, but it is
still very useful.

Cheers

AGL

---

From: Geoffrey Keating <[email-masked]>
Date: 05 Jun 2012 16:41:44 -0700

> would reasonably cause SSLv3-only servers to reject the ClientHello.

Why would you need to send the extensions?  (The RFC says they're
optional.)

---

From: Adam Langley <[email-masked]>
Date: Tue, 5 Jun 2012 19:51:47 -0400

> Why would you need to send the extensions?  (The RFC says they're

Well, we could cross our fingers and hope that the server picks
something acceptable I guess (or simply define the set of acceptable
values for SSLv3). But extending SSLv3 to support ECDHE seems rather
specific:

There's also the issue of captive portals which tend to trigger
fallbacks by doing things like sending HTTP replies on port 443. If
the user authorises during the fallback process then we downgrade to
SSLv3, omit SNI and throw a nasty certificate error for any SNI
requiring domain names. I'd rather throw a network error than a
certificate error that trains users to ignore them. (This has actually
been happening to some of our users, although we significantly
ameliorated it by being more aggressive in stepping back up to TLS
after a fallback.)

Cheers

AGL

---

From: Geoffrey Keating <[email-masked]>
Date: 05 Jun 2012 17:06:56 -0700

> values for SSLv3). But extending SSLv3 to support ECDHE seems rather

I think I'll go out on a limb and say that there are not any
SSLv3-only servers which actually support ECDHE, so if you fall back
to SSLv3 and yet ECDHE gets picked, you're under a downgrade attack
and the appropriate thing is to close that connection (and fall back
up, or whatever).  It doesn't matter what the server picks for the
parameters, you'd never want to use them.

Likewise there are probably not any SSLv3-only clients which support
ECDHE, so if you're a server and you get such a request, you can
probably close that connection too.

---

From: Adam Langley <[email-masked]>
Date: Tue, 5 Jun 2012 20:44:26 -0400

> probably close that connection too.

It sounds like you basically agree with the plan, you just want to
reuse an ECDHE ciphersuite value for it :)

Cheers

AGL

---

From: Chris Richardson <[email-masked]>
Date: Tue, 5 Jun 2012 21:11:22 -0400

On Tue, Jun 5, 2012 at 4:39 PM, Adam Langley <[email-masked]> wrote:
> feature: ECDHE.
...
> handshakes that included this ciphersuite with a fatal error.

Thinking through various scenarios... if I'm a TLS-capable server that
does not support foward-secure cipher suites, what reason would I have
any reason to reject an SSLv3 hello containing the TLS_CAPABLE_SCSV?

 -- Chris

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 5 Jun 2012 18:18:38 -0700

ECDHE is not the only feature we lose when downgrading to SSLv3. We
also lost all the features implemented using TLS extensions, such as
server name indication, OCSP stapling, and the ability to negotiate
SPDY.

It would be nice if the server could indicate support of TLS in a less
destructive way than rejecting the handshake.  Perhaps a new alert
message at the warning level?

As for TLS_1_1_CAPABLE_SCSV and TLS_1_2_CAPABLE_SCSV, it seems that
TLS_1_2_CAPABLE_SCSV could be useful because TLS 1.2 is important to
the people who want to avoid SHA-1 and MD5 or comply with NSA Suite B.

Wan-Teh

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Jun 2012 08:17:24 +0300

> any reason to reject an SSLv3 hello containing the TLS_CAPABLE_SCSV?

Because the client says it supports TLS, but is connecting using SSLv3. That is evidence of a downgrade attack. Regardless of what benefit the attacker intends to get from downgrading the connection to SSLv3, it should be aborted.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Jun 2012 08:20:32 +0300

> the people who want to avoid SHA-1 and MD5 or comply with NSA Suite B.

TLS 1.1 may also be important to people, because it is not vulnerable to the BEAST attack. With TLS 1.0 you have to use RC4 to avoid being flagged by PCI compliance scans and SSL Pulse.

And NIST has long recommended to avoid RC4.

Yoav

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 6 Jun 2012 09:12:55 +0200

On Tue, Jun 5, 2012 at 10:39 PM, Adam Langley <[email-masked]> wrote:

[...]
> forward secure ciphersuites.

In the situation you describe, I see two issues:
1. Various TLS extensions never mention whether they should be
implemented in SSL 3.0. I've raised that previously in this ML [0]
with no particular outcome. An alternative way to this issue is to
explicitly allow SSL 3.0 to use elliptic curves.
2. The fallback strategy implemented by the browsers is weaker than
the TLS protocol itself. The TLS protocol protects only if you do a
fallback within the protocol.

and btw why fallback to RSA and not DHE-RSA if forward secrecy is an
issue? There are techniques to bring DHE-RSA efficiency close to
elliptic curves.

[0]. http://www.ietf.org/mail-archive/web/tls/current/msg08509.html

> TLS_CAPABLE_SCSV would only be included when the handshake was the

What will happen if the attacker makes such a handshake fail? Would
browsers reconnect without this ciphersuite? (I remember there used to
be SSL servers that closed the connection once encountered with a
ciphersuite they didn't understand).

Who will benefit from that?
1. Is that a user that wanted forward secrecy? In that case using
DHE-RSA would mitigate the issue.
2. Is that a user that did not want to use SSL 3.0? Then SSL 3.0
should have been disabled.

regards,
Nikos

---

From: Geoffrey Keating <[email-masked]>
Date: 06 Jun 2012 00:25:15 -0700

> reuse an ECDHE ciphersuite value for it :)

I think the whole fallback thing is terrible, and I don't agree with
it at all.  But if we must do it, then this makes it slightly better,
and does so without standardizing bad practice.  (I think it also
works with many existing hosts, therefore making the deployment
problem significantly simpler.)

---

From: Chris Richardson <[email-masked]>
Date: Thu, 7 Jun 2012 18:34:54 -0400

(replying to the entire list this time...)

As a server, I could:
1: Support TLSv1 and SSLv3, and not support the SCSV
2: Support TLSv1 and SSLv3, and support the SCSV
3: Support TLSv1 but not SSLv3, and the SCSV is irrelevant.

With (1), I'm willing to support SSLv3 for anyone.
With (2), I'm wiling to support SSLv3, but only for clients who aren't
TLSv1 capable.
With (3), I'm unwilling to support SSLv3 for anyone.

Behind the SCSV is the suggestion is that SSLv3 should be considered
harmful.  If SSLv3 is harmful, then why only reject it for
TLSv1-capable clients?  Why not reject it for everyone?

(One benefit of the SCSV that I can see is that a downgrade-to-SSLv3
attack can be detected, which would be an indication that SSLv3 should
be considered harmful, even if we don't know why.)

---

From: Tom Ritter <[email-masked]>
Date: Thu, 7 Jun 2012 19:23:07 -0400

> be considered harmful, even if we don't know why.)

This proposal, and a few others being worked on in various places, aim
to address the problem we have with hard fail and backwards
capability. In some scenarios TLSv1, DNSSEC, DANE, etc all fail not
because someone is performing an attack, but because some piece of
software can't handle some portion of the secure protocol.  And
because Operating Systems and Browsers have an incentive to make
things work for their users, they retry will less, or no, security.
Attackers can exploit this mechanism to get the advantages of the
lesser form (less or no security).

If we don't move the line in the sand forward, if we don't make a
decision that says "We will support this buggy or incomplete software
no more", there's no point in defining new security protocols.  What's
the point in DNSSEC if it only is used when someone's not attacking
you?  What's the point in TLSv1, 1.1, or 1.2 if the security gains
(correct IV, DHE, AEAD, SHA256) will never be realized when there's an
attacker there?

If there's a practical way to detect an attacker trying to downgrade
you, that doesn't shred the protocol, I think it's pretty useful.
SCSV's are ugly and a slippery slope, but when someone in an accurate
position tells you "We're going to have the fallback behavior for a
long time" one or two more to gain the advantage of these new
protocols looks pretty good.  (The other approach being taken is
drawing a little enclave and saying "In this zone, we will hard fail,
and if your software can't handle TLS1.0 or DNSSEC, people can't
connect to you.", but that's not really applicable here.)

> should have been disabled.

I would say it was a user who wanted to use the more secure version of
the protocol available, and not be downgraded by an attacker.

> problem significantly simpler.)

Reusing a ECDHE ciphersuite is standardizing less of a bad practice,
but it's more un-intuitive. Does ECDHE indicate support of ECDHE or
TLS 1.0?  (An AES-GCM ciphersuite would conclusively indicate TLS 1.2
- until we have TLS 1.3)

Would it make sense to define all three: TLS_1_{0,1,2}_CAPABLE_SCSV
and send only the highest one from the client?  I think if people are
adding in the code to handle the SCSV, the code could be written in a
sturdy and reusable way such that adding a fourth later on wouldn't
even require a code change, just another item to an array.

-tom

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 08 Jun 2012 09:35:01 +0200

> (correct IV, DHE, AEAD, SHA256) will never be realized when there's an

I don't quite get the point. If the goal of the attacker is to perform
denial of service on the secure protocol so that the user uses the
insecure protocol (plaintext), how does this approach help? It doesn't.

If you want to only prevent against the attacker that wants to rollback
the session to SSL 3.0, then all you need to do is to perform the proper
TLS protocol negotiation, which protects against that. If it doesn't
work warn the user.

In reality however, there is the fact that several buggy servers do not
implement the TLS protocol but rather a wrong variant of it, that fails
performing the fallback.

To account for that issue several browsers perform non-standard TLS
version fallback in a way that is not protected by the handshake.
Hacking the protocol to understand and detect this non-standard fallback
will create another protocol in par with the TLS protocol, which we have
no guarantees that will be better implemented than the original protocol.

What happens if we have a buggy server that incorrectly implements the
fallback detection mechanism? We define another one?

If the problem is incorrect implementations, then just fix the incorrect
implementations. If you cannot, then do not interoperate with them. If
all major browsers do that, the owners would fix it.

My point is that TLS is already complex. Making it more complex will not
make it easier to implement it, but harder, and it will introduce more
points of failure and interoperability rather than less.

regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Fri, 8 Jun 2012 11:18:08 -0400

> TLS protocol negotiation, which protects against that. If it doesn't

Yes, the aim is to prevent an attacker performing a downgrade attack to SSLv3.

Warning the user assumes that the user can understand what we're
trying to tell them which is not true here.

> fallback detection mechanism? We define another one?

The SCSV for the renegotiation indication extension was deployed
without any serious issues, which is strong evidence that we can
viably deploy other SCSV values.

> all major browsers do that, the owners would fix it.

It's not clear, from a global point of view, that the benefits of
avoiding SSLv3 downgrades exceed the cost of updating all these
servers. By definition these servers are unmaintained and probably
very expensive to update. They're also quite numerous.

Certainly, from a moral point of view, we should not be baring the
costs of these server's bugs. By abandoning these buggy devices on the
network, vendors (which presumably turned a profit by doing so) are
imposing externalities on the world. It's basically a form of
pollution.

I understand and share an anger towards these practices but, none the
less, we find ourselves with these barrels of toxic waste lying around
and have to deal with it. It's the cost of an open network and I'd
still choose it over a closed network.

Cheers

AGL

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 09 Jun 2012 00:08:50 +0200

> trying to tell them which is not true here.

It may not be true, but what would you do if the SCSV check fails?
Wouldn't you warn the user? Why do you think he'd better understand that
warning? Most probably he'd say that your browser doesn't work. Let's
try the other one (which doesn't support SCSV and thus wouldn't detect a
possible attack).

> viably deploy other SCSV values.

Indeed, but this was the case in initial TLS deployments. You rarely
have issues when you implement the protocol you defined, the issues
arise when 3rd parties try to implement their understanding of your
protocol. What if a new server comes out that the SCSV fails for some
random reason? I agree that it helps to mitigate some problem, but my
concern is, does any gain obtained justify the introduced protocol
complexity?

regards,
Nikos

---

From: Adam Langley <[email-masked]>
Date: Mon, 11 Jun 2012 11:29:44 -0400

On Fri, Jun 8, 2012 at 6:08 PM, Nikos Mavrogiannopoulos <[email-masked]> wrote:
> Wouldn't you warn the user?

We would either go back to TLS, or return the original network error
that caused the fallback. We're not going to try telling the user that
they "may be under attack" or such.

> Most probably he'd say that your browser doesn't work. Let's

That's always a possibility but the argument that users will try other
browsers, while true, is also true of many other changes that we've
made: rejecting tiny EDH groups, rejecting RSA keys < 1024-bits,
rejecting MD4 and MD5 signatures. With each of these we have,
undoubtedly, lost users to browsers that don't implement these things.
But we have also motivated people to fix things and provided cover for
other browsers to make the same changes. This tension between breaking
things for the common good and keeping users happy always exists in
large software and I know that this proposal, even for just SSLv3,
will break users behind a certain vendor's firewall product. But
that's a cost to be balanced rather than a fatal flaw (and I'm already
taking to that vendor).

> What if a new server comes out that the SCSV fails for some
> random reason?

Once we start to use the SCSV, we draw a line in the sand and it's
much less likely that there will be compatibility problems in the
future.

> I agree that it helps to mitigate some problem, but my

Well, the complexity decision depends substantially on an individual's
preferences. I obviously believe that this is worthwhile: the SCSV is
a relatively minor addition and the downgrade attack is real. But from
my point of view the protocol is already subject to several of these
warts [1] that the specified protocol doesn't include. This would be a
rather obvious wart on the spec, even if it's not so big compared to
my reality.

[1] http://www.imperialviolet.org/2011/02/04/oppractices.html

Cheers

AGL

---

From: [email-masked] (Martin Rex)
Date: Mon, 11 Jun 2012 19:55:33 +0200 (CEST)

> TLS_CAPABLE_SCSV would only be included when the handshake was the

Similar to my criticism of Eric's original proposal, I very much dislike
new proposals that try to make communication fail, rather than succeed.

How about changing the proposal to indicate what cipher suite IDs were
meant to be used for in the first place:  A specific set of algorithms
to use for protection of the communication, and in a fashion that it
can be included with an extension-free SSLv3 ClientHello or even
an initial SSLv2 CLIENT-HELLO.

i.e. define a _small_ set of cipher suite IDs that imply:
 - one single (or a very small set of) namedCurves for ECDHE
 - implied support of SHA256 for digital signatures
 - implied support of TLSv1.0 (or the version that you consider appropriate)

and allow the server to use this implied information for processing
the ClientHello, rather than what is conveyed in other places of
ClientHello for backwards compatibility, including sending back
a ServerHelloExtension for supported Elliptic Curves.

For robustness/easier implementation, it should be specified
that these special cipher suites should be ignored whenever an explicit
Supported Elliptic Curves Extension is present in ClientHello.

-Martin