Subject: Concluding discussion on #612 (9.2.2)

From: Mark Nottingham <[email-masked]>
Date: Tue, 7 Oct 2014 16:57:49 +1100

I'd like to get to a call for consensus on <https://github.com/http2/http2-spec/issues/612> very soon.

To help get us there, I've prepared a wiki page that I think summarises the issues that have been raised:
  https://github.com/http2/http2-spec/wiki/TlsRequirements

Martin has made a proposal in the form of a pull request:
  https://github.com/http2/http2-spec/pull/615
... and it looks like there's general support for incorporating it. Does anyone have a reason not to?

Greg has made a number of proposals, listed in short form at:
  http://www.w3.org/mid/CAH_y2NH=skUXk0QwCs4uVqWE=[email-masked]

Martin and Greg, do you need time to develop your proposals any further?

Greg, you made quite a few proposals -- did I miss any others, or do you want to selectively nominate one or more of them for consideration?

Finally, does anyone else wish to make a proposal?

Regards,

--
Mark Nottingham   https://www.mnot.net/

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Oct 2014 03:30:42 -0400

As I said before, I don't really have a dog in this fight, but I note
that one of Greg's proposals is to write 9.2.2 more precisely:

   - rewrite 9.2.2 in more precise language (no 'such as')

In that spirit, I suggest the following text which I believe fits
Note that this is not a claim that it addresses Greg's
concern -- that is for Greg to decide -- but merely an attempt to
formalize what I believe the current text already implies.
The last sentence is arguably too conservative, but is intended
to resolve potential ambiguities about future non-AEAD ciphers and
in any case will be easy to deal with.

  HTTP2 MUST NOT be used with cipher suites that use stream [RFC5246;
  Section 6.2.3.1] or block [RFC5246; Section 6.2.3.2]
  ciphers. Authenticated Encryption with Additional Data (AEAD) modes
  [RFC 5246; Section 6.2.3.3]) are acceptable.  At present, the only
  such modes defined for TLS are the Galois Counter Model (GCM) mode for
  AES [RFC5288] [RFC5289; Section 3.2] and Counter with CBC-MAC Mode
  (CCM) [RFC665] [RFC7251], but any future AEAD modes are also
  acceptable. Any future TLS modes that are not of the AEAD form MUST
  NOT be used without an RFC updating this document.

Hope this helps.

-Ekr

On Tue, Oct 7, 2014 at 1:57 AM, Mark Nottingham <[email-masked]> wrote:

> I'd like to get to a call for consensus on <
> https://github.com/http2/http2-spec/issues/612> very soon.
>
> Greg, you made quite a few proposals -- did I miss any others, or do you
> want to selectively nominate one or more of them for consideration?
>

---

From: Michael Sweet <[email-masked]>
Date: Tue, 07 Oct 2014 09:38:41 -0400

I still don't like having this kind of requirement since, at present, there is no way for me to enforce it and still support HTTP/1.1 without some after-the-fact oops code that shuts things down.

> On Oct 7, 2014, at 3:30 AM, Eric Rescorla <[email-masked]> wrote:
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Nicholas Hurley <[email-masked]>
Date: Tue, 07 Oct 2014 09:19:16 -0700

I'm fine with Martin's PR, and would even be fine combining it somehow
with ekr's proposal up-thread. They make the language clearer. Any
weakening or removal of the language in 9.2.2 gets a big "no" from me.

On Mon, Oct 6, 2014, at 22:57, Mark Nottingham wrote:
> I'd like to get to a call for consensus on
> <https://github.com/http2/http2-spec/issues/612> very soon.
> 

-- 
Peace,
  -Nick

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Oct 2014 09:23:12 -0700

On 7 October 2014 00:30, Eric Rescorla <[email-masked]> wrote:
> Any future TLS modes that are not of the AEAD form MUST

I can certainly take the rest of the text, but this makes me uncomfortable.

I noted previously that the check is simple:
  isOK = isForwardSecrecyCapable && !isStream && !isBlock

That statement would introduce some potential ambiguity based on the
potential for a future RFC.

Though I can live with it if that is the consensus.

---

From: Jason Greene <[email-masked]>
Date: Tue, 7 Oct 2014 11:59:29 -0500

Can we please consider simply requiring TLS 1.3 as a replacement to the wording in 9.2.2?

Failing that we really need a commitment from all major TLS stacks to provide the APIs necessary to implement 9.2.2 with HTTP 1.1 compatibility. Failing that I argue that 9.2.2 should be abandoned, as its proper implementation will be mutually exclusive with HTTP 1.1 support.

The API requirements for TLS implementation are:

A) The TLS stack must provide clients with a way to order forward DH & aead (and future stronger cipher classes) with a higher preference than block and stream ciphers. This should be specified using characteristics instead of hard coded cipher names, as hard coding cipher names excludes future ciphers. Alternatively stronger cipher classes do not need to be allowed if 9.2.2 is restricted to TLS 1.2, and 9.2.2 provides a hardcoded list of ciphers.

B) The TLS stack must provide servers with a way to order h2 *acceptable* ciphers (DH & aead & anything stronger) above other ciphers in contradiction to the client’s preference list. (Same note on characteristics based or TLS 1.2 hardcoding as above)

C) The TLS stack must provide a characteristics based introspection API to determine whether or not DH & AEAD were used after negotiation.

Note that a simple requirement on TLS 1.3 is vastly superior to the implementation complexity of the above, since the protocol negotiation/handshake is part of the cipher selection process, whereas in the TLS 1.2 case, we rely on ordering magic and abstraction breaking APIs.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 7 Oct 2014 11:24:54 -0700

> Though I can live with it if that is the consensus.

I would also be fine with defaulting in the other direction. I.e., any new
ciphersuite is default OK unless stated otherwise. Again, I'm just aiming
for clarity.

-Ekr

---

From: "Albert Lunde" <[email-masked]>
Date: Tue, 7 Oct 2014 13:34:01 -0500

TLS 1.2 introduces the GCM ciphers that have the "holy grail" properties, so
there's nothing wrong with parts of 1.2, it's just a question of how to deal
with the legacy ciphers. But an API that gives a version number check won't
draw the line at the right place.

-----Original Message-----
From: Jason Greene [mailto:[email-masked]] 
Sent: Tuesday, October 07, 2014 11:59 AM
To: Mark Nottingham
Cc: HTTP Working Group; Martin Thomson; Greg Wilkins
Subject: Re: Concluding discussion on #612 (9.2.2)

Can we please consider simply requiring TLS 1.3 as a replacement to the
wording in 9.2.2?

Failing that we really need a commitment from all major TLS stacks to
provide the APIs necessary to implement 9.2.2 with HTTP 1.1 compatibility.
Failing that I argue that 9.2.2 should be abandoned, as its proper
implementation will be mutually exclusive with HTTP 1.1 support.

A) The TLS stack must provide clients with a way to order forward DH & aead
(and future stronger cipher classes) with a higher preference than block and
stream ciphers. This should be specified using characteristics instead of
hard coded cipher names, as hard coding cipher names excludes future
ciphers. Alternatively stronger cipher classes do not need to be allowed if
9.2.2 is restricted to TLS 1.2, and 9.2.2 provides a hardcoded list of
ciphers.

B) The TLS stack must provide servers with a way to order h2 *acceptable*
ciphers (DH & aead & anything stronger) above other ciphers in contradiction
to the client's preference list. (Same note on characteristics based or TLS
1.2 hardcoding as above)

C) The TLS stack must provide a characteristics based introspection API to
determine whether or not DH & AEAD were used after negotiation.

Note that a simple requirement on TLS 1.3 is vastly superior to the
implementation complexity of the above, since the protocol
negotiation/handshake is part of the cipher selection process, whereas in
the TLS 1.2 case, we rely on ordering magic and abstraction breaking APIs.

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat

---

From: Rob Trace <[email-masked]>
Date: Tue, 7 Oct 2014 20:13:39 +0000

Our feedback on the proposals listed below is that we cannot live with 9.2.2 being in the HTTP/2 spec and favor Greg's proposal of "move 9.2.2 requirements to a document that applies to h1 and h2."  Implementers who enforce section 9.2.2 will require a new platform in the TLS layer to integrate HTTP/2 specific decision making. There have been responses in the list from implementers who implement on top of general purpose TLS platforms who may not be able to enforce this section.  Ironically, if this section did not exist or was written as a SHOULD, HTTP/2 would already negotiate to a modern crypto suite the majority of the time.  Making this mandatory will have detrimental effects:
 
- It will slow adoption of HTTP/2 as implementers have to wait for new TLS platforms which can enforce section 9.2.2.
- It increases the likelihood that there will be non-conformant implementations of HTTP/2 in the wild.
- It creates more fragility in the negotiation of HTTP/2 and increases the likelihood of interop issues.
 
Historically this type of document is separate from the core protocol, either a standard from the TLS working group (ala 2818) or a BCP from the UTA working group like what is being defined for HTTP 1.1.

-Rob

-----Original Message-----
From: Michael Sweet [mailto:[email-masked]] 
Sent: Tuesday, October 7, 2014 6:39 AM
To: Eric Rescorla
Cc: Mark Nottingham; HTTP Working Group; Martin Thomson; Greg Wilkins
Subject: Re: Concluding discussion on #612 (9.2.2)

> In that spirit, I suggest the following text which I believe fits Note 
> that this is not a claim that it addresses Greg's concern -- that is 
> for Greg to decide -- but merely an attempt to formalize what I 
> believe the current text already implies.
> The last sentence is arguably too conservative, but is intended to 
> resolve potential ambiguities about future non-AEAD ciphers and in any 
> case will be easy to deal with.
> 
>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 7 Oct 2014 14:21:25 -0700

+agl

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 8 Oct 2014 09:03:53 +1100

> want to selectively nominate one or more of them for consideration?

If we really have to enforce TLS acceptability in the application protocol,
then we need to do so with a robust handshake.   Thus I would like to leave
aside my arguments about the need for TLS restrictions and expand on one of
my proposals to a concrete pull request.

I will write a pull request tomorrow, but the basic approach will be to
replace the text:

Clients MAY advertise support of cipher suites that are prohibited by
the above restrictions in order to allow for connection to servers
that do not support HTTP/2.This enables a fallback to protocols
without these constraints without the additional latency imposed by
using a separate connection for fallback.

With something along the lines of

Clients MUST NOT advertise support of cipher suites that are prohibited by
the above restrictions if they advertise support for HTTP/2.  If a connection
is refused due to lack of a mutually acceptable cipher a client MAY retry the
connection with weaker ciphers, but it MUST NOT offer support HTTP/2.

The intent of this is to make the success/failure of the handshake
independent of the definition of 'h2 acceptable cipher'.  While 9.2.2 might
be considered well defined now, I doubt it will remain so when confronted
with reality and the future.   H2 acceptability is and will be a matter of
configuration. Configurations will be deliberately or unintentionally non
9.2.2 compliant and the protocol should handle such configurations
gracefully.

The handshake must succeed IFF there is a mutually acceptable
protocol/cipher pair and it must never fail with inadequate security if
there is a mutually acceptable protocol/cipher pair.

I will spend some time tomorrow to develop this into a pull request with
more precise wording.

If we have a robust handshake, then I'm happy to leave it to people more
qualified than I am to debate what ciphers are acceptable and who should
say so.

cheers

-- 
Greg Wilkins <[email-masked]>
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Oct 2014 15:10:25 -0700

> connection with weaker ciphers, but it MUST NOT offer support HTTP/2.

I suspect that no browser can implement that requirement and remain competitive.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 8 Oct 2014 09:44:16 +1100

> I suspect that no browser can implement that requirement and remain

I don't accept that this whole mess is because the browser vendors are
unwilling to risk their commercial concerns to achieve good security
practises.    I am sure there is a win-win solution where the IETF can
achieve our goal of technical excellence and the browser vendors can
achieve commercial success.

To borrow a metaphor used already used on this subject:  The current 9.2.2
is holding h2 as hostage to try to enforce good ciphers.  This proposal is
for a hostage exchange of h1 for h2.  Instead of threatening to kill the h2
hostage in a game of Russian roulette , this proposal is just to slow down
the h1 hostage only if it insists on using weak ciphers.

If we want to encourage both good ciphers and h2 adoption, then let's not
set them up in competition to each other.   Instead, let's add an impost to
weak h1 servers to encourage them to move to better ciphers.

It is not acceptable to have a fragile handshake and many implantations
have already declared they will not implement 9.2.2 as is. So if this
proposal for a robust handshake is not acceptable to browser, then please
propose an alternative that is because the status quo is not.

regards

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 8 Oct 2014 09:49:03 +1100

> I suspect that no browser can implement that requirement and remain competitive.

I'm wondering if we should explore selectively relaxing the requirement to generate INADEQUATE_SECURITY, since that's where the pain seems to be coming from.

E.g., if it were SHOULD/MAY, a party that wants to promote better security can do so by generating INADEQUATE_SECURITY, forcing fallback to HTTP/1 (and thereby losing the performance benefit of the protocol, giving an incentive to their peer to update).

Those that don't wish to do so can simply not generate INADEQUATE_SECURITY.

I think this should work as long as the fallback is interoperable (not necessarily performant).

Cheers,

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 7 Oct 2014 15:54:24 -0700

Explicitly +agl since he's not subscribed to the mailing list. And I'm
deferring the Chromium/Google stance to him.

---

From: Jason Greene <[email-masked]>
Date: Tue, 7 Oct 2014 19:36:49 -0500

> draw the line at the right place.

The desired “parts” of 1.2 happen to be the exact 1.3 restrictions. So what’s happening here is 9.2.2 is trying to require 1.3 semantics without sending the required {3, 4} version identifier during negotiation which is what creates these handshaking issues.

---

From: Brian Smith <[email-masked]>
Date: Tue, 7 Oct 2014 18:06:18 -0700

On Tue, Oct 7, 2014 at 1:13 PM, Rob Trace <[email-masked]> wrote:
> Our feedback on the proposals listed below is that we cannot live with 9.2.2 being in the HTTP/2 spec and favor Greg's proposal of "move 9.2.2 requirements to a document that applies to h1 and h2."

AFAICT, that is not even an option at this stage, without risking
significant delay and/or making the protocol less secure.

It seems that some people think that 9.2.2 is in the specification due
to some kind of unnecessary advocacy effort for better cryptography.
While I think it is good if it has that effect, 9.2.2 is really in the
the specification because it addresses real security and performance
concerns.

Many months ago, I was asked, as I'm sure others were, to provide
feedback about the interaction of TLS and HTTP/2. In particular, is
HTTP/2 as safe to use as HTTP/1.1 with RC4? Is HTTP/2 as safe to use
as HTTP/1.1 with TLS 1.0 CBC-mode cipher suites? My feedback, and I
believe the others' feedback, was that it was a waste of time to try
to prove that HTTP/2 is as safe to use as HTTP/1.1 in these
dysfunctional configurations of TLS. That is why I supported making
RC4, SSL 3.0, and TLS 1.0 MUST NOTs.

Those restrictions were added to an HTTP/2 draft a long time ago (a
year ago?), and they've remained in the draft (actually, the draft has
gotten more strict) for a very long time. Consequently, nobody even
bothered to do a security analysis of HTTP/2 using these dysfunctional
configurations of TLS, on the assumption that these restrictions would
remain in place. As it currently stands, it doesn't make sense, given
what we know about these security footguns, to allow them with HTTP/2,
because we don't have a clear idea if they are safe to use in
conjunction with HTTP/2.

While RC4, SSL 3.0, and TLS 1.0 have obvious known problems, it seems
to me that the restrictions beyond prohibiting those three things are
more about prevention of as-yet-unknown problems. I think that that
preventative effort will pay off down the road, probably sooner than
later. Plus, if we'd have the no-RC4, no-SSL 3.0, and no-TLS 1.0
restrictions anyway to address practical known concerns, I don't see
how the additional TLS 1.2, AEAD, and ephemeral key exchange
requirements are a significant additional burden.

The biggest benefit of HTTP/2 is better performance & efficiency. The
use of ephemeral key exchange, the symmetric cipher used, and probably
eventually the version negotiated, are factors used by many clients
will choose to do False Start or not. The False Start optimization is
one of the most important optimizations for HTTP. Having the HTTP/2
specification require a TLS configuration that is roughly the
intersection of what enables False Start for all major browsers is
itself enough of a reason to leave things 9.2.2 in the spec.
Otherwise, implementations will have to indefinitely continue to make
significant and otherwise-unnecessary, security-for-performance
trade-offs.

So, again, 9.2.2 serves a real purpose in the spec independently from
any "better/ideal crypto" advocacy effort. At this point, after 9.2.2
has been in the drafts for so long, and because people have relied on
that to avoid the cost of doing additional (wasteful, IMO) security
analysis, the burden of responsibility for doing any additional
security analysis for HTTP/2 with currently-prohibited configurations
of TLS falls on the people that want to remove 9.2.2, before the
working group should even consider doing so.

Cheers,
Brian

---

From: Patrick McManus <[email-masked]>
Date: Tue, 7 Oct 2014 21:10:01 -0400

I strongly support 9.2.2 as written.

The big picture: We know the best practices for application protocol
security and they are reflected in 9.2.2. To mint a protocol at this point
that doesn't guarantee, for example, forward secrecy does not pay heed to
the needs of the modern day Internet and the IETF consensus that it is
being attacked by eavesdroppers  (BCP 188).

I don't find either of the common criticisms of 9.2.2 compelling. One
argument is some variation of scope and standing wrt the TLS wg. But we've
established that TLS-wg is perfectly comfortable with applications
profiling TLS, 9.2.2 is consistent with the direction of TLS 1.3, and
explicit coordination on this point was used in the authoring of 9.2.2.

The other criticism is really an API implementation concern. 9.2.2. is
robustly implemented when there is coordination between cipher suite
selection, TLS version, and ALPN selection. It is true that h2 requires new
code and new interfaces to be implemented for some TLS implementations - I
don't see why 9.2.2 is a particularly special burden in that regard. ALPN
is a useful existence proof - it is also a required part of h2, it also
requires changes to TLS libraries, and we've seen movement on adoption of
it. The internet moves on - h2 implementations will need new code; that's
not an inherent criticism of h2.

-Patrick

On Tue, Oct 7, 2014 at 8:36 PM, Jason Greene <[email-masked]>
wrote:

> The desired “parts” of 1.2 happen to be the exact 1.3 restrictions. So
> what’s happening here is 9.2.2 is trying to require 1.3 semantics without
> sending the required {3, 4} version identifier during negotiation which is
> what creates these handshaking issues.
>
> --
> Jason T. Greene

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Oct 2014 19:15:37 -0700

I was talking to someone about new research into attacks on RC4, and was
asked if HTTP/2 was potentially interesting. In particular, they were
looking for interesting information in the first 256 bytes of a session,
where the biases are most easily exploited. I noted that it might be
interesting - header compression results in less boilerplate - if it
weren't for the fact we had prohibited use of RC4.
On Oct 7, 2014 6:06 PM, "Brian Smith" <[email-masked]> wrote:

> > Our feedback on the proposals listed below is that we cannot live with
> 9.2.2 being in the HTTP/2 spec and favor Greg's proposal of "move 9.2.2
> requirements to a document that applies to h1 and h2."
>

---

From: Roland Zink <[email-masked]>
Date: Wed, 08 Oct 2014 13:25:09 +0200

On 08.10.2014 03:10, Patrick McManus wrote:
> security and they are reflected in 9.2.2. To mint a protocol at this 
> point that doesn't guarantee, for example, forward secrecy does not 
> pay heed to the needs of the modern day Internet and the IETF 
> consensus that it is being attacked by eavesdroppers  (BCP 188).
>
> argument is some variation of scope and standing wrt the TLS wg. But 
> we've established that TLS-wg is perfectly comfortable with 
> applications profiling TLS, 9.2.2 is consistent with the direction of 
> TLS 1.3, and explicit coordination on this point was used in the 
> authoring of 9.2.2.
>
> selection, TLS version, and ALPN selection. It is true that h2 
> requires new code and new interfaces to be implemented for some TLS 
> implementations - I don't see why 9.2.2 is a particularly special 
> burden in that regard. ALPN is a useful existence proof - it is also a 
> required part of h2, it also requires changes to TLS libraries, and 
> we've seen movement on adoption of it. The internet moves on - h2 
> implementations will need new code; that's not an inherent criticism 
> of h2.
An API extension just to repair something the protocol doesn't do seems 
weird. I would expect the TLS cipher negotiation and ALPN protocol 
negotiation do the right thing and not to fallback to the application.

Roland

---

From: "Albert Lunde" <[email-masked]>
Date: Wed, 8 Oct 2014 07:25:51 -0500

Another side to the questions of TLS ciphers and modes is that pretty much everything that is a security risk to HTTP/2

Is a security risk to HTTP/1.1.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 8 Oct 2014 16:17:46 +0300

> not an inherent criticism of h2.

Then 9.2/9.2.2 should explicitly call out requirements for TLS stacks
for reliable operation, even if no current TLS stack meets those.

Regarding application protocols standardization, when faced with bad
or even nonexistent support for required features, some back off, some
don't.

The problems with 9.2./9.2.2.
- It allows endpoints to assume properties of ciphersuites, instead of
  requiring querying TLS stack at runtime, leading to serious risk of
  interop failure[1][4][6].
- It does not require server to enforce the restrictions on handshake time
  [1].
- It allows server to send GOAWAY(INADEQUATE_SECURITY). This is never
  necressary if the handshake actually worked[5].
- It allows advertising HTTP/2 if ClientVersion is not maximal (fallback).
  Using non-maximal ClientVersion is just asking for trouble[2].
- It contains no explicit requirement for client to finish handshake even
  if requirements fail. Any behaviour change as response to aborted handshake
  is no-no[2].
- It is confusing, especially some of the examples confuse instead of clarify
  (the mentions of AEAD and AES-GCM are the worst[3]). And getting these
  things wrong causes interop problems.
- It wrongly assumes DHE and ECDHE are the only PFS key exchanges.

The "fragility" some have talked about is the first two plus the confused
interpretations.

Note that requiring TLS 1.2+ is not on this list. It is trivial to do
with present-day TLS stacks and is well-supported. Additionally, there is
plenty of percedent for requiring minimal (D)TLS versions.

Disabling RC4 specifically is not trivial to do, but still quite easy.
And if RC4 is mentioned specially, calling out concerns about it is
entierely justfied. Heck, there is "publication requested" I-D about
completely prohibiting RC4 usage in TLS.

[1] Even if this probably requires TLS stack upgrades.
[2] I hope there are no TLS libraries retarded enough for this to cause any
implementation problems.
[3] This has apparently been gotten wrong multiple people.
[4] "disable what you don't undestand" 1) May not be reliable, 2) May lead
to actually more secure stuff getting disabled (I have personally seen this
happen, and I got very annoyed).
[5] RST_STREAM(INADEQUATE_SECURITY) could be useful in some cases, E.g.
buggy client trying to request https:// in plaintext. Or some special
material having even higher cipher requirements.
[6] Have the same TLS library on both sides, and sometimes one sees really
"interesting" TLS ciphersuites (fortunately those are almost invariably much
stronger than RC4-based ones).

-Ilari

---

From: Patrick McManus <[email-masked]>
Date: Wed, 8 Oct 2014 09:45:26 -0400

On Wed, Oct 8, 2014 at 8:25 AM, Albert Lunde <[email-masked]> wrote:

> Another side to the questions of TLS ciphers and modes is that pretty much
> everything that is a security risk to HTTP/2
>

Brian and Martin have argued against the clarity of exactly that argument
just a couple messages back in this thread. The mux and compression
properties of h2 mean h2 and h1 interact with TLS in different, perhaps
meaningful, ways.

But beyond that, fixing such things in h1 breaks interop with
implementations that were conformant when they were shipped. h2 doesn't
have the same legacy concerns. This is the chance to clear the decks of
legacy-enforced algorithms. We know what that looks like, and draft-14
captures it.

-P

---

From: Brian Smith <[email-masked]>
Date: Wed, 8 Oct 2014 09:26:50 -0700

> Is a security risk to HTTP/1.1.

In some cases, HTTP/1.1 implementations have had to make tough choices
based on the precise framing of their HTTP messages (e.g. what order
they send certain HTTP headers in). In some cases, some problems were
not fully mitigated because backward compatibility wouldn't allow it
and the risk for HTTP/1.1, given its specific on-the-wire properties,
was deemed not severe enough to break that compatibility.

In fact, it would be a good idea for implementations that are now
using SPDY with less restrictive TLS configurations than allowed for
HTTP/2 to reconsider whether that is a good idea.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Wed, 8 Oct 2014 09:37:58 -0700

>   interop failure[1][4][6].

On the other hand, allowing implementations leeway in handling this
may improve interop, at least in the short term, until more
server-side TLS stacks are extended to provide better support for
this.

>   Using non-maximal ClientVersion is just asking for trouble[2].

I support adding language to 9.2.2 that says something like "If the
client's TLS ClientHello.client_version indicates a version lower than
TLS 1.2, then the client MUST NOT offer HTTP/2 in its ALPN extension."
After all, it doesn't make sense for the client to offer HTTP/2 in a
configuration where it is guaranteed to reject it.

>   if requirements fail. Any behaviour change as response to aborted handshake

Such a requirement would be harmful. In fact, I wish the requirement
went the other way: If the client detects that the minimum
requirements in 9.2.2 are not met and HTTP/2 is negotiated, then the
client MUST NOT complete the handshake. Otherwise, you have to worry
about the server pushing application data to the client between the
time the client finishes the handshake and the time that the client
sends the INADAEQUATE_SECURITY message. (I can see how this race could
occur and be problematic in the Firefox implementation, for example,
because Firefox is likely to finish the handshake well before it
considered it safe to send the INADAEQUATE_SECURITY message.)

>   things wrong causes interop problems.

I agree that the attempts to clarify in 9.2.2 that AEAD cipher suites
and AES-GCM are acceptable seem to be having the
opposite-from-intended effect on clarifying things.

> - It wrongly assumes DHE and ECDHE are the only PFS key exchanges.

Do you have a suggestion for improving that?

Cheers,
Brian

---

From: Adam Langley <[email-masked]>
Date: Wed, 8 Oct 2014 10:46:59 -0700

> deferring the Chromium/Google stance to him.

We can live with or without the requirements in 9.2.2 but, if 9.2.2 is
struck, we might still have its requirements in code. Everything less
than TLS 1.2 with an AEAD mode is cryptographically broken and nothing
new should be using anything less.

A requirement on TLS 1.3 would be fine, except for the fact that TLS
1.3 doesn't exist yet and isn't likely to for some time.

I think that Jason Greene's enumerated requirements are roughly
correct, but I also think that TLS stacks already implement the needed
functions. Since it would be a static configuration error to have
HTTP/2 enabled with an SSL configuration that could lead to an invalid
state, I hope that it's not too burdensome to check. Indeed, if the
server is configured with weak cipher suites as a high priority, even
without HTTP/2, it would be nice to warn about that.

Cheers

AGL

---

From: Jason Greene <[email-masked]>
Date: Wed, 8 Oct 2014 14:23:15 -0500

> Do you have a suggestion for improving that?

Yes, require TLS 1.3, or alternatively a revision to TLS 1.2 that introduces a 3, 4 version, and 1.3 becomes 3, 5 :)

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 9 Oct 2014 15:30:31 +1100

I've created https://github.com/http2/http2-spec/pull/626

I've taken Eric's more precise wording for 6.2.2 and gone a bit further.
For TLS1.2 it now simply white lists DHE and ECDHE key exchange and black
lists block and stream ciphers.     This should be about as unambiguous as
it gets.

I've made TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support only a SHOULD, as
it is conceivable that a vulnerability in that cipher will be discovered
while TLS1.2 is still in use.

I have moved the h1 fallback to a section 9.2.3 which is written so that a
Client may not offer a cipher that it subsequently rejects due to
inadequate security.  This addresses my fragile handshake concern, so that
if circumstances for implementations to violate 9.2.2, it will not result
in communications failure.

For those who don't like reading diffs, the resulting text is:

9.2.2 TLS 1.2 Cipher Suites

The set of TLS 1.2 cipher suites that are permitted in HTTP/2 is restricted.

HTTP/2 MUST only be used with ciphers that exchange keys with either: ephemeral
Diffie-Hellman (DHE) [TLS12] with a minimum key exchange size of 2048; or
the elliptic curve variant (ECDHE) [RFC4492] with a security level of at
least 128 bits. Clients MUST accept DHE key exchange sizes of up to 4096
bits.

HTTP/2 MUST NOT be used with Null or Standard Stream Ciphers (Section
6.2.3.1) [RFC5246] nor CBC Block Ciphers (Section 6.2.3.3) [RFC5246].

The effect of these restrictions is that TLS 1.2 implementations could have
non-intersecting sets of available cipher suites, since these restrictions
prevent the use of the TLS 1.2 mandatory ciphers. To avoid this problem,
implementations of HTTP/2 that use TLS 1.2 SHOULD support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186].
  9.2.3 Cipher Negotiation

A Client that advertises support for the HTTP/2 protocol, MUST NOT
advertise support for a cipher suite that it will subsequently reject with
a connection error (Section 5.4.1) of type INADEQUATE_SECURITY. For the
purposes of backwards compatibility with HTTP/1 Servers, a Client MAY retry
a failed connection with ciphers prohibited by the above restrictions, but
it MUST NOT offer HTTP/2 support with the retry.

On 9 October 2014 06:23, Jason Greene <[email-masked]> wrote:

> Yes, require TLS 1.3, or alternatively a revision to TLS 1.2 that
> introduces a 3, 4 version, and 1.3 becomes 3, 5 :)
>
> --
> Jason T. Greene

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Oct 2014 22:00:08 -0700

> while TLS1.2 is still in use.

I don't really understand the reasoning here. This consideration applies
for the existing MTI cipher suite, which is inherited by HTTP1, and yet
it is still a MUST. The impact of this change is that there would be
no guaranteed interop cipher suite.

> in communications failure.

This seems like an extremely problematic suggestion, for at least two
reasons.

1. It is going to have a negative impact on performance on clients
which offer H2. The reason is that a significant fraction of the existing
H1 servers on the Internet do not support TLS 1.2 and therefore will
not be able to negotiate with the client if the client only supplies AEAD
cipher suites (as required by your 9.2.2). In those cases the client will
have to fall back to a new TLS handshake, with obvious latency impacts
Much of the point of ALPN is that you can offer H2 support without risk,
because sites which don't want to support it can just ignore ALPN, but
this change breaks that invariant and effectively penalizes clients for
offering H2.

2. Unless I misunderstand, this change allows an attacker to force you
down from H2 to H1 by simulating a negotiation failure (note that these
are not authenticated in TLS) and then causing you to reconnect with
H1 only. There may be ways to mitigate this, but it would require some
thought to design them and they might well require changes to TLS.

Moreover, I don't understand what this change achieves. In the current
case, if the client and the server disagree about which ciphers are
acceptable for H2 (and specifically if the server likes some cipher for
H2 that the client does not) then you get a successful TLS connection
but the H2 stack generates an error. At this point, the client could retry
if it wished.

With the design you propose, the server generates a TLS-level failure
(probably handshake_failure) and then the client retries. How is that
better?

-Ekr

> The effect of these restrictions is that TLS 1.2 implementations could
> have non-intersecting sets of available cipher suites, since these
> restrictions prevent the use of the TLS 1.2 mandatory ciphers. To avoid
> this problem, implementations of HTTP/2 that use TLS 1.2 SHOULD support

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 9 Oct 2014 16:31:54 +1100

On 9 October 2014 16:00, Eric Rescorla <[email-masked]> wrote:

>> which offer H2.
The issue is that ALPN does not allow ciphers to be offered conditionally.
Wanting to avoid a second round trip in order to support h1 with weak
ciphers
does not mean that ALPN support it.

So either: 0) we don't restrict cipher differently for h1/h2; 1) we enhance
ALPN to allow ciphers to be protocol dependent; or 3) we design a handshake
that works with existing ALPN that is not fragile.

This PR is a proposal for 3).   I would look at it as penalising servers
that do
not accept strong ciphers rather than as penalising clients that offer h2.
But I'm open to other proposal to make the handshake robust?

> if the client and the server disagree about which ciphers are

That was my very first suggestion way way back at the start of this whole
thread.
It was unacceptable but I can't recall why.

But that would work for me, so long as it was a MUST that any client
offering
weak ciphers for h1 compatibility would retry without h2 if one of those
ciphers is
accepted for h2.

I'll prepare a PR for that as well.

regards

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 9 Oct 2014 17:06:39 +1100

Eric,

Here is a variation of the previous PR:
https://github.com/http2/http2-spec/pull/627

I've reverted TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 to a MUST and switched
the connection retry case to only when a client does inadequate security on
a cipher it was offering
for h1 fallback.

So most connections will be 1 round trip for old and new servers.  There
will be 2 round trips IFF a client chooses to offer weak ciphers for h1
fallback and there is a difference with 9.2.2 interpretation.  A client can
avoid having to implement the retry if it chooses to never offer a cipher
that it will not accept for h2.

Then no matter what the future brings in terms of ciphers, if a client and
server share a cipher/protocol pair then they will be able to connect.
This allows us to be strict in 9.2.2 - with the knowledge that if
circumstances do force deployment of non 9.2.2 compliant ciphers, we do not
risk communication failure.

regards

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 9 Oct 2014 13:36:04 +0300

> risk communication failure.

Why did you assume that PFS is the same as DHE/ECDHE key exchange? That's not
true even in current TLS.

How does this handle version skew (and "surprise" ciphers), both at client and
server? One can get ciphersuites that are UNKNOWN if those are 9.2.2-compliant
(without TLS introspection APIs, that one presumably can't assume present).

E.g. How does server behave if it gets E413 (???) negotiated somehow,
a ciphersuite it has no idea what it is? What about client in comparable
situation[1]?

Disabling any ciphers as response to TLS handshake abort (which is
completely unauthenticated[2]!) is a VERY bad idea (the proposal does not
say to do it, but neither it says to not do it)[3].

[1] At least those version skew/"surprise" ciphers are unlikely to be weak
(might not be the best ciphers around, but should at least be fit for
the purpose).

[2] Even the certificate can not be trusted to not be forged until handshake
completion (not that mismatched ciphersuites even get that far).

[3] At least if fallback connect happens with the same TLS version and
the same ciphers, the server will probably pick some rather good cipher,
and not some bad cipher like RC4.

-Ilari

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 9 Oct 2014 22:16:18 +1100

Ilari,

I'll take your comments out of order:

On 9 October 2014 21:36, Ilari Liusvaara <[email-masked]>
wrote:

> server?

Both proposals handle surprise ciphers by having a strong handshake that
will not fail to connect if
an end point decides that an unknown cipher is h2 acceptable.   If both end
points decide that
a new cipher is h2 acceptable then it may be used for h2 - regardless if it
fits the 9.2.2
compliance or not.    But most importantly, the strong handshake allows one
end-point to take that
step without risking connection failure.

The entire point of having a robust handshake is to handle the unexpected
development in ciphers.
It is the current handshake that is fragile when presented with surprise
ciphers.

> One can get ciphersuites that are UNKNOWN if those are 9.2.2-compliant

As it has been said many times here, an end point can choose to be 9.2.2
non compliant.
This proposal allows that to happen without risk of connection failure.
Note that it does
not mean that an end-point can expect or demand that the other end also be
9.2.2
compliant.    Each end-point is ultimately responsive for the ciphers it
will accept.

Why did you assume that PFS is the same as DHE/ECDHE key exchange? That's
> not

I didn't assume.      I looked for an definition of "ephemeral key", but
could not
find anything more rigorous than wikipedia.  So I instead simply white
listed the ciphers that
were given as "such as" examples in the original text.    If there are more
key exchanges that
need to be white listed, then we can add them.  Unknown surprise mechanism
will be covered
by the robust handshake above.    If there is a good standard definition of
what ciphers have
ephemeral keys, then I'm happy to reference that.

> say to do it, but neither it says to not do it)[3].

Neither proposal implies disabling ciphers in response to a handshake abort.
The first proposal adds ciphers and removes h2 from a retry.  The second
proposal
just removes h2 from a retry.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Oct 2014 07:42:10 -0700

But the problem is that those servers already exist and so the variable
behavior
is what clients do. I don't want to speak for Patrick, but I would be
surprised
if Mozilla were willing to make a change to Firefox that would cause an
extra
set of round trips for a large fraction of the Web servers in the world.

> It was unacceptable but I can't recall why.

I don't recall this discussion, but in any case your current proposal seems
less
good for the reasons I laid out.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Oct 2014 09:39:16 -0700

> that it will not accept for h2.

Good news!  This is the intent of 9.2.2.  Let's see if I can figure
out how to apply your changes to my PR (which includes a number of
other fixes).

---

From: Martin Thomson <[email-masked]>
Date: Thu, 9 Oct 2014 09:43:12 -0700

> true even in current TLS.

I think that's just a common misconception about the (EC)DHE key
exchange.  That is, that they offer PFS (they can, but don't
necessarily), and that they are the only options.  The current text in
9.2.2 is very careful on this point.

> (without TLS introspection APIs, that one presumably can't assume present).

Surprise ciphers might trigger the behaviour Greg is recommending.
That's why we recommend that you don't offer ciphers you don't
understand, and don't select them.  Obviously, this might still happen
with some combinations of implementations.

> say to do it, but neither it says to not do it)[3].

This is not what is being recommended.  What is being recommended is
disabling h2 in response to an inability to negotiate h2.  That's far
less of a problem.

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 10 Oct 2014 14:09:34 +0300

> It is the current handshake that is fragile when presented with surprise
 
What about following case:

1) Client sets priority "NORMAL:-KX-ALL:+PFS:-MAC-ALL:+AEAD" (offer only
   (most of) 9.2.2-compliant ciphers).
2) Client sets mandatory ALPN to ["h2"] (HTTP/2 only).
3) Client connects to server.
4) Server TLS stack picks ALPN "h2" and ciphersuite XYZ (must be 9.2.2-
   compliant because of 1).
5) The HTTP/2 stack has no (or only partial[1]) idea what XYZ is.

Does the server generate INADEQUATE_SECURITY?

If yes, you get interop failure (with client that did nothing wrong).

If no, one potentially lets some[2] non-9.2.2 ciphers through.

> proposal just removes h2 from a retry.
 
Might be a good idea to explicitly say not to downgrade TLS version or
remove any ciphersuites.

[1] On some TLS stacks, it might be possible to reliably identify e.g.
PFS, NULL or RC4 ciphers, but not stream/block ciphers.

[2] If by nothing else, query for the ciphersuite number or name and run
it against blacklist of bad ciphersuites (if one has names, one can build
a reasonable blacklist with a couple of regex's[3]).

[3] The following should pick most of the stuff:

NULL ciphers:			.*_WITH_NULL_.*
EXPORT ciphers:			.*_EXPORT_WITH_.*
RC4:				.*_WITH_RC4_[0-9]+_.*
CBC (block ciphers):		.*_CBC_[^_]*
RSA key exchange:		TLS_RSA_.*
PSK key exchange:		TLS_PSK_WITH_.*
Non-PFS Diffie-Hellman:		TLS_[^_]*DH_.*

(Note: There are some cipher names that typo DHE_PSK as PSK_DHE)

-Ilari

---

From: Jason Greene <[email-masked]>
Date: Fri, 10 Oct 2014 09:51:24 -0500

> If no, one potentially lets some[2] non-9.2.2 ciphers through.

This proposal is certainly a major improvement, but I think they only it can work if it exhaustively lists the allowed h2 ciphers, which effectively means new ciphers require either TLS 1.3, or an update to the RFC to list them. I’d be ok with something like this, and would look forward to TLS 1.3 coming out soon, and hope this ugly hack vanishes.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 11 Oct 2014 08:38:23 +1100

> If no, one potentially lets some[2] non-9.2.2 ciphers through.

So the client send a handshake saying that it would only speak h2 and gave
a list of ciphers, some of which it is not prepared to speak h2 over? That
is a pretty strange case, but then real world deployments do through up
strange things like this, so the handshake must handle.

But what I'm advocating is that if a client offers a protocol/cipher pair -
then either it will accept it's use or it MUST retry with protocol/cipher
pairs that it will accept.   So I will change my PR so that instead of
saying it must fallback to h1, to instead say that it must fallback to only
acceptable protocol/cipher pairs.

Offering unacceptable pairings and hoping the server will never see those
as acceptable is fragile.   If you don't like my proposals for a robust
handshake, then please make your own.   A fragile handshake is not an
option.

regards

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Oct 2014 14:47:05 -0700

On Fri, Oct 10, 2014 at 2:38 PM, Greg Wilkins <[email-masked]> wrote:
> as acceptable is fragile.
>

This ship has already sailed:
TLS clients regularly offer TLS 1.2 with AEAD cipher suites but will accept
TLS 1.1. However, the AEAD cipher suites are forbidden with TLS 1.1.

-Ekr

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 11 Oct 2014 01:23:13 +0300

On Sat, Oct 11, 2014 at 08:38:23AM +1100, Greg Wilkins wrote:
> a list of ciphers, some of which it is not prepared to speak h2 over?

Nope, all ciphers it gave are both acceptable for it and 9.2.2-compliant.

It is the server that doesn't know. It can't verify that XYZ is 9.2.2-
compliant, nor can it know that XYZ is not 9.2.2-compliant.

-Ilari

---

From: Jason Greene <[email-masked]>
Date: Fri, 10 Oct 2014 21:59:52 -0500

On Oct 10, 2014, at 4:47 PM, Eric Rescorla <[email-masked]> wrote:

> Offering unacceptable pairings and hoping the server will never see those as acceptable is fragile. 
> 

Right but in that case the real need to downgrade is made clear by the TLS version differential. It also sounds like there will be a downgrade SCSV that is widely accepted.

In the case of INADEQUATE_SECURITY, the peer doen't really know what action to take other than to give up on H2 and use H1. 
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 11 Oct 2014 18:00:56 +1100

> Nope, all ciphers it gave are both acceptable for it and 9.2.2-compliant.

So there is no problem.  Any cipher the server picks is acceptable to the
client for h2, so the handshake will succeed.

If the server does not know XYZ and thus decides to not accept it according
to 9.2.2, then the handshake will fail unless there is another cipher suite
(or protocol) that the server is prepared to talk.  If failure occurs in
this circumstance, then it is because there is not a mutually acceptable
cipher/protocol pair.    The server is entitled to reject XYZ if it does
not know it.  Or the server can be more trusting and say that it does not
know XYZ, but the client is prepared to speak it for h2, so it will also.
That all depends on the server security policy - which it is entitled to
enforce.

Handshake failures may still happen if there are no mutually acceptable
cipher/protocol pairs.   The issue I want to see fixed is the handshake
failures when there are mutually acceptable cipher/protocol pairs.

regards

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 11 Oct 2014 11:35:30 +0300

> client for h2, so the handshake will succeed.

But the server won't know that.

> (or protocol) that the server is prepared to talk. 

Only if it rejects XYZ at TLS handshake time, which it was assumed not to.

> If failure occurs in
> cipher/protocol pair.  

There may be. But the time server replies to TLS handshake attempt from
client, the number of ciphers is already down to 1.

>  The server is entitled to reject XYZ if it does

The whole point is that after TLS stack has negotiated XYZ, the server
can't reject it anymore without interop. failure against correct client
implementation unless the server actually knows it is not 9.2.2.-acceptable.

Obviously, if server had powerful enough cipher introspection[1], then the
this case could not arise, because server could classify every cipher
to either 9.2.2.-acceptable or 9.2.2.-unacceptable with 100% accuracy and
100% precision.

And unless server supports variant ALPN (which is the second thing that
can't be assumed[1]), then one can't disable XYZ just for h2.

> That all depends on the server security policy - which it is entitled to

Yes, if server admin wants to disable ciphers they think are insecure
or they have to disable for compliance reasons[2], let them.

> failures when there are mutually acceptable cipher/protocol pairs.

In the above example, the client and server might have another cipher
that both think is acceptable, but TLS cipher selection resulted a
problematic one.

[1] If TLS stacks reliably had variant ALPN and powerful enough cipher
introspection, then the only real problems in 9.2.2 as originally written
would be ECDHE min-key-length requirements[3] and that it is written in
confusing way.

[2] E.g. taking "sensitive cardholder data", one should disable SSL
3.0 and TLS 1.0 as per PCI DSS.

[3] One can interpret the "minimum of 128 bits" as DQing P-256, as
security measured as resistance against combined rho and PH would
be ~127.8 bits (and indeed, "Safecurves" says that P-256 has
security of 127.8 bits).

-Ilari

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 12 Oct 2014 09:13:44 +1100

On 11 October 2014 19:35, Ilari Liusvaara <[email-masked]>
wrote:

> implementation unless the server actually knows it is not 9.2.2.-acceptable

Ilari,

OK I get what you are illustrating now.   Yes it is indeed a problem to
implement 9.2.2 at all
if the server cannot influence the selection of the cipher.

But this is an argument against having 9.2.2 at all - as this is a problem
that results from making
protocol specific cipher requirements in environments where the protocol
implementation is not party
to the cipher negotiation.

Indeed if the client only offers h2, and XYZ and the server has got XYZ in
it cipher suites that the TLS
layer can accept, but then decides that XYZ is not h2 acceptable - then it
is in a mess.        But that
problem exists regardless of my proposal for a retry.   The solution to
that problem is to not have
protocol specific cipher requirements - I'm fully OK with that!

regards

---

From: Jason Greene <[email-masked]>
Date: Sat, 11 Oct 2014 18:03:18 -0500

On Oct 11, 2014, at 5:13 PM, Greg Wilkins <[email-masked]> wrote:

> 
> On 11 October 2014 19:35, Ilari Liusvaara <[email-masked]> wrote:
> OK I get what you are illustrating now.   Yes it is indeed a problem to implement 9.2.2 at all 
> But this is an argument against having 9.2.2 at all - as this is a problem that results from making
> protocol specific cipher requirements in environments where the protocol implementation is not party
> Indeed if the client only offers h2, and XYZ and the server has got XYZ in it cipher suites that the TLS
> layer can accept, but then decides that XYZ is not h2 acceptable - then it is in a mess.        But that 
> problem exists regardless of my proposal for a retry.   The solution to that problem is to not have 

Right, its big a mess. The downgrade attack vectors that Martin refers to are certainly a real issue, and you need [1] to fix it, which TLS 1.3 implementors are looking likely to have (unless they do not support old protocols). So the issue with the “MUST" is we have to also hope that TLS 1.2 stacks also implement this.

If we were after a clean solution, we would simply require TLS 1.3. It’s the right way to mandate TLS 1.3 behavior. It would be great to hear why we simply can’t wait for TLS 1.3 to finish.

Looking at the TLS 1.2 hacks that offer non-fragile handshakes, we have:

1) Ilari’s modification to your proposal:
   a) Clients have a white list of h2 accepted ciphers
   b) Servers have a black list of h2 unacceptable ciphers
   c) Clients must reconnect if the server doesn’t support those ciphers
      i) TLS stacks need [1] to mitigate MITM downgrade 
2) TLS implementations commit to the rich APIs I referred to in an earlier email. According to Michael Sweet’s analysis, nearly all do not. I think it will take quite some time before this is practically available, perhaps when TLS 1.3 is already out.
3) Exhaustively specify the allowed ciphers with TLS 1.2 for both client and server, for both H1 and H2. The XYZ cipher scenario above will not be a problem, because the client will be barred from using it, until either TLS 1.3 comes out, or an H2 revision occurs to add it.

Theres one final hack:

4) Keep a broken spec, and punt to the admin. Basically if the server provides a mechanism to override 9.2.2 in order to fix the version-skew issues then at least its a temporary interop problem. To help the administrator the server could log that it was not familiar with the cipher, and was forced to exclude it. 

[1] https://tools.ietf.org/html/draft-bmoeller-tls-downgrade-scsv-01
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Adrian Cole <[email-masked]>
Date: Tue, 14 Oct 2014 21:55:22 -0700

This is a meta-comment.

The current text would requires a cipher suite not available until
Android L [1]. Other options discussed have short-term implementation
risk. I'd suggest that once folks smarter than me decide what the
ideal text is, we add another column to the implementations page, on
that tracks which actually can enforce this.

https://github.com/http2/http2-spec/wiki/Implementations

Hope this suggestion helps,
-A

[1] https://github.com/square/okhttp/issues/959

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 15 Oct 2014 17:01:42 +1100

Is that significantly different than the case for ALPN (WRT Android -- I see it's still "FutureRelease" according to <https://code.google.com/p/android/issues/detail?id=56942>)?

Cheers,

---

From: Adrian Cole <[email-masked]>
Date: Tue, 14 Oct 2014 23:08:58 -0700

That one's complicated, Mark :)

So ALPN went in Android 4.4, but we had a crash and reverted it. That
crash hasn't been fixed [1]. In other words, ALPN doesn't work today,
but it might soon?

-A

[1] https://code.google.com/p/android/issues/detail?id=67940