Re: Stricter TLS Usage in HTTP/2

> I don’t understand the objection. Chrome, as a TLS client, can propose
any list of ciphersuites that is acceptable to its developers. Just as IE
unilaterally disabled RC4, and pretty much all browsers have disabled RC2
at some point (each doing this unilaterally), why is it unacceptable for
Chrome to do this now for the non-AEAD version of AES-CBC? (yes, there’s an
AEAD version [1], although no TLS ciphersuites are defined)
>
> As for the proposal itself, the HTTP version is negotiated in the same
ClientHello as the list of supported ciphersuites. Making the chosen
ciphersuite depend on the version of HTTP selected introduces some new
logic to TLS. I don’t think this should be added to the HTTP spec.

We already have this capability, and it isn't what you describe, quite.

Basically, clients, particularly browsers, will need to offer all the sites
they do today, unless they want to regress performance in a big way (hint:
not going to happen). So the ClientHello contains lots of suites we don't
like, sometimes even RC4. Though Microsoft have made the courageous choice
to allow a regression there to reduce the likelihood that RC4 is used, good
for them.

The ClientHello will include http/1.1 and h2. But we are saying that you
can't select h2 unless you select a "good" suite. Given normal selection
processes in the software I know, as long as both parties have good suites,
those will be chosen.

Now the potential change here to software is in servers who might like to
follow the "SHOULD" in the draft and fall the handshake. NSS can do that,
but I recognize that not all software is created equal, so the draft
permits the handshake to complete. Clients have to do that check anyway.
The HTTP/2 implementation need only add a little code like what Will
shared, and it's good.

The problem with that is that if any implementation hard fails a connection
because of a suite the spec permits, they effectively create an alternative
de facto spec. One that isn't documented. Their peers would have to know
about this so that they wouldn't cause breakage when they deploy HTTP/2.