Subject: [TLS] Fixing CBC Mode II: Indicating new GenericBlockCipher construction

From: Eric Rescorla <[email-masked]>
Date: Sun, 29 Dec 2013 15:16:28 -0800

WG Members,

We have seen two major proposals for indicating the use of a fixed
GenericBlockCipher construction:

- Use a TLS Extension
- Use an SCSV

Either of these will work within the context of TLS negotiation.

However, because some browsers do version fallback to compensate
for extension intolerance, the extension approach is potentially
subject to active attackers simulating extension-intolerant
servers. It therefore must be paired with something to prevent
fallback, such as:

- Refusal to fall back below TLS 1.0 (which requires extension
  tolerance)

- An ancillary anti-fallback mechanism, such as:
  draft-bmoeller-tls-downgrade-scsv-01 (the requirement
  here would likely be something like the server MUST support
  this draft if they support the new CBC mode).

The alternate SCSV approach does not have this problem, but as
a number of people have suggested, it is inelegant to keep adding
a lot of additional SCSVs.

If you have something to say about this issue, please do so
between now and January 10. We would particularly like to hear
from browser vendors about which approaches they believe are
viable given the existing server and intermediary infrastructure.

-Ekr
[For the chairs]

---

From: Adam Langley <[email-masked]>
Date: Sun, 29 Dec 2013 19:35:37 -0500

> - Refusal to fall back below TLS 1.0 (which requires extension

Tried it in general in Chrome 31 and it was painful due to buggy,
local MITM proxies on Windows.

>   this draft if they support the new CBC mode).

In ~3 months I hope to know whether
draft-bmoeller-tls-downgrade-scsv-01 is viable on a large scale. If it
turns out to be then the extension would be preferable as the SCSV
wouldn't be needed. I don't object to the SCSV if people wish to get
something done sooner.

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 30 Dec 2013 00:41:45 +0000

> - Use a TLS Extension

I prefer the TLS Extension approach, combined with a required
anti-fallback mechanism: largely because I think we really need the
anti-fallback mechanism deployed (as urgently as I think we need to
deprecate RC4 as no longer suitable for any purpose!), and my
perception is that one security upgrade would be easier than two.

But agreed: I'm particularly interested in browser/server/endpoint
vendors' viewpoints about how practical that would be in real terms,
as that is where the challenge is likely to be.

And also, where the practicality problems are likely to arise: I think
that may indicate troublesome infrastructure that a nation state
adversary (or, indeed, any adversary, if the fruit is low-hanging
enough) would find particularly fruitful for attack (or at the least,
simply very convenient): and therefore, I think would warrant much
closer audit to see what else is likely to be up with it; and,
perhaps, ideas on how we could encourage more rapid deployment of fixes.

Bluesky thought on that note: Would, say, a BCP for TLS perhaps be
something we could potentially point standards bodies like PCI SSC to,
as a clear master reference for SSL/TLS to use to ensure 'the protocol
in use only supports secure versions or configurations' - and,
thereby, strongly encourage large, slow-moving sites that they _really
need_ to take action because they would face compliance problems if
they don't? Could that help?

- -- 
/akr

---

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Dec 2013 21:37:41 -0500

On Sun, Dec 29, 2013 at 7:41 PM, Alyssa Rowan <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

The BCP you are looking for was sent to UTA WG instead, and they've
done nothing with it.
The author has no clue what is holding it up.
>
> - --
> /akr
> -----BEGIN PGP SIGNATURE-----
>
> iQIcBAEBCgAGBQJSwMFJAAoJEOyEjtkWi2t6qqIP/jSJdRHVtOvQgDc//fJB+Svz
> 6hFagrUiJCqb7kZRUgY+Bf5dsOWW9gOqJEJqjZHz8KzAfG2nuQkVAQWqggFhxlmn
> bZz5LzEsalRTknefOb1322B+/buQmdeijRgcAjmvIpvXlHbbNjKVvcVtfz4QCNda
> hPKd2h/rvS7qnxDc8NCSSyO6o0BUFEj3TZ2ru2TgvqSukRWodxAvmLUZeSK7xOva
> OZ7YOWvMikpCoxx9+uflyQYPHyOnQcPEnEb15YGseeZmotX3HgpDyFFPOf5Sx8Z9
> femzi1TaTyXeF1JC7NH0kh4kW3I/9ATCqevfBLCSqCwmhPTeHgIEv1npXJzpLhKy
> mQTJyYspbaveFJU0elJOJaDfnUd0t+wcjz2xRrsRFON+QtALqNK49Y37SJwFwHYw
> DEkLRyFJ5kQhH1SXcGyuWbR3wRzxAtYMQJ4pD5f9hQKkyQ/20aikTR+nfX3i9aVw
> LadcEGZPcLYgJimDghD29LYgZdjPFedolfLvI88e51XhgDmk0QaCjcjR69V2mR/o
> JuWFOWJIhnjW9YlzZstaBbWkxeeM095CIh6g93qYZZWg7vmiE08E0NW6/ETE+Gui
> Dzery0wqYtXnCjflv3x6/dKasn9+kZjVl+9z82kkQhh0EknVRA3YpidzD0dHcy+X
> ZXx3QlMsp7llcqu9+ysk
> =JMqm
> -----END PGP SIGNATURE-----
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 30 Dec 2013 12:56:54 +0200

> The author has no clue what is holding it up.

Hi Watson,

The said BCP (https://ietf.org/doc/draft-sheffer-tls-bcp/) is in fact 
waiting for the newly formed UTA working group to adopt it formally. 
This WG has not published yet a list of deliverables. In fact, there is 
nothing extraordinary about this process delay, especially given the 
holiday period.

Thanks,
	Yaron

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Dec 2013 11:12:04 +0000

> GenericBlockCipher construction:

I may be missing something, but you anyway need an extension for the server to signal to the client that it agrees to the use of a fixed GenericBlockCipher, no?

So the actual question is not whether to use an SCSV or an extension, but whether to define and SCSV *in addition to* the extension (as in RI) or to forego it (as in every other TLS extension ever)

I would go with an extension only, and here's why:
An extension-intolerant server is not going to emit the server hello extension either, and it not going to support this extension either. Browsers today emit many extensions, so an extension-intolerant server is going to force a downgrade anyway.
Extension-intolerant middleware will force the client to drop the extensions. If the client persists in sending the SCSV, the middleware may miss it and forward the ClientHello to the server. In that case, the server will reply with an extension, that the middleware will drop. Besides, with an SCSV we have to deal with this:
 Client                  Server
CH with extensiosn -->
       <--- RST
CH without extensions but with SCSV
          ----------->
       <--- SH with extension

I guess Yngve will tell us that this is a way (for the server) to detect a downgrade attack.

But I don't see where an SCSV will give us any benefit.

Yoav

---

From: Tom Ritter <[email-masked]>
Date: Mon, 30 Dec 2013 10:53:40 -0500

On 30 December 2013 06:12, Yoav Nir <[email-masked]> wrote:
> If the client persists in sending the SCSV, the middleware may miss it and
> forward the ClientHello to the server. In that case, the server will reply with
> an extension, that the middleware will drop.

Are you certain about this? I haven't seen anyone talk about
middleware intolerant to a _server's_ extensions, just a client's. I
just tested my server (Apache/OpenSSL) with a SSL v3 handshake. I sent
no extensions, I received a response with the renegotiation extension.
If middleware dropped server hellos with extensions, I believe we'd
see a lot more broken internet, as servers will not downgrade their
options. Right?

-tom

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Dec 2013 16:14:14 +0000

> see a lot more broken internet, as servers will not downgrade their

Hmm, hadn't thought of that. Come to think of it, RI did introduce the (apparently) unsolicited serverHello extension. I'm wondering if clients downgrade to SSLv3 without SCSV if SSLv3 with SCSV fails. Probably not. Extension-intolerant proxies are pretty rare, but it seemed to me that if they were intolerant of users sending extensions, they would be equally intolerant of servers sending them. 

So maybe SCSV does have some value here.

Yoav