Subject: Discussion of 9.2.2

From: Mark Nottingham <[email-masked]>
Date: Wed, 24 Sep 2014 12:17:03 +0100

We’re burning a lot of cycles on the TLS cipher suite requirements, and producing much heat but little light. Discussion seems to be looping, in part because people either aren’t reading the current spec language, or are drawing the wrong conclusions from it.

The actual requirements there are:

1) HTTP/2 MUST only be used with cipher suites that have ephemeral key exchange [plus details].
2) HTTP MUST NOT be used with cipher suites that use stream or block ciphers.
3) 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.

<http://http2.github.io/http2-spec/#rfc.section.9.2.2>

Further discussion needs to be directly related to this text — if you draw conclusions, please do so by illustrating how THESE requirements will result in an interop problem.

As discussed, the TLS WG has been consulted on the current text; there is not a process problem inherent here. Furthermore, an implementation roadblock in a single platform, while unfortunate, is not grounds for changing the protocol on its own. 

That being the case, those who still think we have a problem need to convince the rest of the WG that this is the case — so far, I don’t see that happening.

—

My personal observations (no chair hat):

AIUI, the crux of the purported problem is when a new cipher suite X is introduced, and a client offers it. If the server supports that cipher suite but the HTTP/2 implementation has not decided that it is conformant to these requirements, INADEQUATE_SECURITY will be thrown.

It seems to me that a few editorial changes would help here. 

a) Explicitly note that INADEQUATE_SECURITY is thrown in 9.2.2 (it’s implied by 9.2 but let’s be explicit). This should happen regardless.
b) Change the start of #2 above to “HTTP/2”. This should happen regardless.
c) Change #2 above to “HTTP/2 MUST NOT be used with cipher suites that are known to be stream or block ciphers.” This emphasises that it’s a blacklist, not a whitelist, and avoids throwing INADEQUATE_SECURITY when encountering a cipher suite with unknown properties.

Regards,

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

---

From: Roland Zink <[email-masked]>
Date: Wed, 24 Sep 2014 16:18:26 +0200

I'm concerned that HTTP2 can't be revised to add or remove ciphers 
without breaking interoperability. When the group isn't concerned about 
this then I don't need to worry.

Roland

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 25 Sep 2014 03:03:51 +1000

Mark,

I am just incredulous that the position adopted appears to be that we know
the fragile handshake will not break in the future because we know how
ciphers will evolve and be deployed in the future.

If the defence of the status quo was not based on such weak foundations or
less intolerant of any change, then perhaps we'd burn less cycles.

the fundamental issue as I see it is that we have designed a fragile
handshake, that if implementations have slightly different interpretations
of 9.2.2 results in communications failure. This was discovered by a real
interop problem albeit from a very poor implementation of 9.2.2 on my
behalf.

So aside from the social argument of should we be doing this or not, I fail
to understand why this WG is rejecting the valid feedback that the
handshake is fragile.     Arguments that are based on predictions of the
evolutions of ciphers for the next few decades to combat the fragility of
the handshake are themselves fragile - no matter how smart the people are
who are making them.

regards

On 24 September 2014 21:17, Mark Nottingham <[email-masked]> wrote:

> We’re burning a lot of cycles on the TLS cipher suite requirements, and
> producing much heat but little light. Discussion seems to be looping, in
> part because people either aren’t reading the current spec language, or are
> drawing the wrong conclusions from it.
>
> 3) 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.
>
> Further discussion needs to be directly related to this text — if you draw
> conclusions, please do so by illustrating how THESE requirements will
> result in an interop problem.
>
> As discussed, the TLS WG has been consulted on the current text; there is
> not a process problem inherent here. Furthermore, an implementation
> roadblock in a single platform, while unfortunate, is not grounds for
> changing the protocol on its own.
>
> That being the case, those who still think we have a problem need to
> convince the rest of the WG that this is the case — so far, I don’t see
> that happening.
>
> —
>
> AIUI, the crux of the purported problem is when a new cipher suite X is
> introduced, and a client offers it. If the server supports that cipher
> suite but the HTTP/2 implementation has not decided that it is conformant
> to these requirements, INADEQUATE_SECURITY will be thrown.
>
> a) Explicitly note that INADEQUATE_SECURITY is thrown in 9.2.2 (it’s
> implied by 9.2 but let’s be explicit). This should happen regardless.
> c) Change #2 above to “HTTP/2 MUST NOT be used with cipher suites that are
> known to be stream or block ciphers.” This emphasises that it’s a
> blacklist, not a whitelist, and avoids throwing INADEQUATE_SECURITY when
> encountering a cipher suite with unknown properties.
>
> Regards,
>
> --

-- 
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: Jason Greene <[email-masked]>
Date: Wed, 24 Sep 2014 12:05:29 -0500

> 3) 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.

AIUI, in order to meet these requirements without impairing usage of future ciphers, all TLS implementations must be updated to provide an API which:

1. Allows an H2 stack to set a strong preference for ephemeral key exchange OR anything stronger, and AEAD or anything stronger. The TLS stack then needs to ensure that all weaker algorithms are still selectable (for H1/legacy compat), but are below the priority list of ephemeral and stronger, and below AEAD and anything stronger. This specification can not use explicit cipher names, only characteristics.
2. Provides a post negotiation introspection API that allows an H2 stack to validate, that if ALPN selected H2, that a weaker cipher was not chosen. This also needs to be characteristic based, in such a way that stronger future characteristics do not fail the test.

In reality it will take some time for TLS APIs to get there, in particular if they are associated with another standards body, so HTTP2 implementations that are not willing to wait will then have to resort to some of the hacks suggested in the other thread. This likely means a number of H2 implementation in the wild overriding the available ciphers with exhaustive and correctly ordered whitelist, and then post validating the selected cipher is on the h2 portion of the whitelist. Any mistake made here results in interop issues. When the TLS stack is updated to include future ciphers, the H2 stacks won’t select them since that would require a code update, which might not be available. This is yet another interop failure potential if a site employees the strictest cipher requirements, and starts requiring ciphers more recent than a peer’s h2 implementation supports, yet its TLS stack would have.

After the industry adopts TLS 1.3, or even uses TLS 1.2 stacks with recent ciphers, the machinery (including the APIs) created to do this social hack ceases to add any value, but it can still continue to cause problems. Before this event occurs the value is very limited, as these old ciphers are still pervasive, since other more prevalent protocols, notably h1, will continue to operate with them.

If 9.2.2 is not dropped, an H2 implementation without access to the above API, is likely best off going the route Roy is taking and simply ignoring the provision. Interop problems will of course crop up, but at least they will be momentary, detectable, and solvable with administrative action.

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Sep 2014 01:30:13 -0700

> a) Explicitly note that INADEQUATE_SECURITY is thrown in 9.2.2 (it’s implied by 9.2 but let’s be explicit). This should happen regardless.

Sure.  I'll add this to my open PR on this general issue.

> b) Change the start of #2 above to “HTTP/2”. This should happen regardless.

Ditto.

> c) Change #2 above to “HTTP/2 MUST NOT be used with cipher suites that are known to be stream or block ciphers.” This emphasises that it’s a blacklist, not a whitelist, and avoids throwing INADEQUA…

The "known to be" is a problem here.  That implies an uncertainty that
would actually reinforce Greg's concerns around fragility and suite
agility.  This is not ambiguous at all; a cipher suite is either a
stream/block cipher or it is not (same goes for the PFS thing).

Based on this discussion, I think that there needs to be a d) here
where we note that implementations MUST NOT offer cipher suites where
these properties (PFS, stream/block mode) are unknown.  This was an
assumption on my part that turns out to be important.  With that
change, I think that the concern about fragility becomes immaterial.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 26 Sep 2014 02:10:19 +1000

> change, I think that the concern about fragility becomes immaterial.

I think that something like that, if it applies to all offered protocols,
will help a bit with the fragility issue.  What that effectively means is
that weak ciphers for h1 fallback can only be offered if they are known by
the client to be non-h2 compliant.

If the server receives an unknown cipher, then it cannot accept h2 on it
and should thus avoid INADEQUATE_SECURITY.  The server will then only
accept h2 if it knows the cipher to be good and it can be reasonably
confident that the client will not be offering a h2 acceptable cipher
unknowingly

However I still have several lingering concerns:

   - Black listing ciphers for which properties are unknown may be a
   significant impediment to the adoption of new better cyphers.
   - Implementations that do not have direct access to the properties of a
   cipher will still probably resort to black/white listing of h2 acceptable
   ciphers.   It will be impossible to prevent such configuration breaking
   your rule d), however having such a configuration will at least reduce the
   barrier to introducing new ciphers...  So INADEQUATE_SECURITY can still
   occur if such configurations are over zealously updated in contradiction to
   9.2.2
   - I am concerned that "No block/stream ciphers except AEAD" is a
   sufficiently future proof specification.  Could there be block/stream
   ciphers that use something other than AEAD to make them sufficiently strong
   for h2?  If so, how would such ciphers be knowingly included?
   - Rather than whitelisting h2 ciphers based on their properties, would
   it not be simpler to.

So a similar counter proposal would be to replace c) with an explicit white
list of currently known weak ciphers that can be offered for h1 fallback.
This list would be immutable as it only exists to transit from known weak
ciphers.

This would give certainty to the sever side if they receive an unknown
cipher.  Since it is unknown, it is not in the h1 fallback whitelist, so it
is not being offered for h1 only.    Thus the server knows that if it
accepts it for h2 the client will also accept it (otherwise it would not
have been offered).

Both the client and server would then be empowered to have their own policy
on using unknown ciphers.  Clients can choose not to offer unknown ciphers
and servers can choose not to accept them.  But the key here is that this
choice is made independent of any protocol selection and can be achieved
through existing white/black list configuration.

regards

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Sep 2014 09:36:47 -0700

On Thu, Sep 25, 2014 at 9:10 AM, Greg Wilkins <[email-masked]> wrote:

> I am concerned that "No block/stream ciphers except AEAD" is a
> for h2?

For the record, I think it's important to be clear that this isn't quite
accurate.

TLS divides cipher suites into three categories:

- block
- stream
- AEAD

So, AEAD isn't an exception, it's a third category. One might imagine adding
a fourth category, but that wouldn't fall afoul of 9.2.2 because 9.2.2
prohibits
block and stream, but doesn't say *only* AEAD.

I realize that it's a bit confusing because AES-GCM is an AEAD primitive
based on a block cipher (AES) [0], but in the TLS taxonomy, that makes it
an AEAD cipher, not a block cipher.

-Ekr

---

From: Roland Zink <[email-masked]>
Date: Thu, 25 Sep 2014 18:50:32 +0200

> block and stream, but doesn't say *only* AEAD.
Assuming somebody invents a fourth category and adds it to TLS then 
servers and clients might out of sync if it is allowed for h2 and 
negotiation may fail.

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 26 Sep 2014 02:52:40 +1000

Eric,

Thanks for that clarification.  I think that explains much of the(my?)
confusion about 9.2.2.

I think this indicates that the wording of 9.2.2 is indeed causing
confusion and has actually created wrong implementations.   In FF the 9.2.2
test is currently implemented as:

   isAEAD()

when it should be:

   !isBlock() && !isStream()

The former is a interoperability problem for future acceptable non AEAD
ciphers, while the later is not.

cheers

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 25 Sep 2014 10:05:16 -0700

> ciphers, while the later is not.

Trying to think this through....

Isn't that only true if we add a new non-AEAD ciphersuite in NSS and then
forget
to update the code in Firefox?

-Ekr

---

From: Michael Sweet <[email-masked]>
Date: Thu, 25 Sep 2014 10:07:05 -0700

> On Sep 25, 2014, at 9:10 AM, Greg Wilkins <[email-masked]> wrote:
> ...
> 	• Implementations that do not have direct access to the properties of a cipher will still probably resort to black/white listing of h2 acceptable ciphers.   It will be impossible to prevent such configuration breaking your rule d), however having such a configuration will at least reduce the barrier to introducing new ciphers...  So INADEQUATE_SECURITY can still occur if such configurations are over zealously updated in contradiction to 9.2.2

This is a serious concern.  SecureTransport does not provide a "properties" API and has no way to specify priority or preference for cipher suites.  So unless I want to limit myself to servers that support HTTP/2-compatible cipher suites (I can't realistically do this), I will need to simply hope that the server will do the right thing or close my client-side connection if it doesn't.

GNU TLS has a notion of priority strings [1], and could potentially support a HTTP2 priority string, but there doesn't appear to be any way to match things up to the 9.2.2 text without resorting to specifying a whitelist.  (at least there you can specify an explicit priority order for cipher suites).

OpenSSL has a similar notion of cipher strings [2], although I'm not certain that you could define a cipher string that matches 9.2.2 and allows future algorithms.

Microsoft's sChannel APIs *may* be able to specify priority (I'm just not sure reading the documentation), but there is definitely no way to pick cipher suites based on properties - you have to specify lists of cipher suites using constants that MS provides.

Based on other posts we know that Java and NSS have similar issues with cipher suite selection and priorities.

I understand the desire to set a higher bar for security, but I just don't see how it can be implemented today without causing problems as soon as a new version of TLS or a new cipher suite is deployed.  Requiring a HTTP/2 implementation to make decisions about TLS cipher suite selection puts TLS interoperability at risk by developers that lack the necessary background or infrastructure (i.e. APIs) to implement it correctly, and that will just hurt adoption and long term use of HTTP/2.

Require TLS 1.2, recommend TLS BCPs, but please don't try to define a profile that is restricted to a version of HTTP that uses the same ports and ostensibly is supposed to work along side older versions of the protocol.

[1] http://www.gnutls.org/manual/gnutls.html#Priority-Strings
[2] http://www.openssl.org/docs/apps/ciphers.html

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Jason Greene <[email-masked]>
Date: Thu, 25 Sep 2014 12:20:03 -0500

> change, I think that the concern about fragility becomes immaterial.

That doesn’t really solve the problem. If you are implementing an H2 stack where the TLS stack it is used with does not provide the rich APIs I described in my previous email, then the only way to meet this requirement is for the H2 stack to specify a whitelist of all ciphers (as doing that suggests it is aware of the properties). Once it white-lists future ciphers used by peers that meet the AEAD (or greater) test will fail.

To use an example:

1. H2 stack X, running on System A hard codes all known H2 compliant 1.2 ciphers
2. Time goes by, and a new stronger cipher C is released (either based on aero, or maybe just a new aead cipher in 1.3)
3. System B is a high security site and only allows cipher C
4. The administrator on System A installs a TLS stack update to latest 1.3, which contains cipher C, so that A can talk to B
5. A now can’t talk to B, and the administrator can’t figure out why, and probably begrudges the switch to H2

On the other hand, if stack X had simply ignored 9.2.2, it all would have worked out fine.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 25 Sep 2014 20:33:54 +0300

> to update the code in Firefox?

Nope. Somebody WILL dynamically link the TLS librariesif the platform
supports dynamic linkage at all (and most non-constrained stuff does).

And even if stock Firefox statically links NSS, there is at least one
rebranded one (checked the memory map) that dynamically links system
NSS (hello version skew!).

-Ilari

---

From: Patrick McManus <[email-masked]>
Date: Thu, 25 Sep 2014 18:47:33 +0100

> NSS (hello version skew!).
firefox explicitly enables the cipher suites it supports - that isn't left
to the defaults of nss.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 25 Sep 2014 18:56:21 +0100

Jason,

> 3. System B is a high security site and only allows cipher C

which is not conformant with "implementations of HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186].” (9.2.2) — assuming it’s still 1.2 (see below). You’re building a straw-man here...

> 4. The administrator on System A installs a TLS stack update to latest 1.3, which contains cipher C, so that A can talk to B

If both parties both speak 1.3, 9.2.2 doesn’t apply, as per recent discussion.

> 5. A now can’t talk to B, and the administrator can’t figure out why, and probably begrudges the switch to H2

See recent discussion regarding the language regarding unknown ciphers. Please address that proposal (mine or Martin’s).

Cheers,

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 26 Sep 2014 04:12:02 +1000

> to update the code in Firefox?

Let's say that a new non-AEAD cipher is added in the future.  At some point
in time there is going to be a split population of FF deployed, some that
do know about it and some that don't.   Those that don't might still offer
the cipher because it is a good desirable cipher for h1.   So we are back
to servers not knowing if a client is offering a cipher as a h2 acceptable
one or not.

Now judging from Patrick's response in this thread, it might not be a
problem for FF if they have to explicitly white list new ciphers (so they
can change that code at the same), but it may be that new ciphers are added
to FF by plugin or other configurations. Also, other clients may not be so
rigorous about vetting new ciphers, and may still have the same isAEAD()
test instead of the more correct !isBlock()&&!isStream()

A handshake that relies on good cipher vetting of the client to work is a
fragile handshake.

The point being that the current text in 9.2.2 encourages implementations
to tread AEAD as a sufficient and necessary condition for a cipher, when in
fact it is just sufficient and not necessary.  If 9.2.2 explicitly said how
future new classes of ciphers should be handled, then we'd avoid this.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 26 Sep 2014 04:14:08 +1000

On 26 September 2014 03:56, Mark Nottingham <[email-masked]> wrote:

>
> See recent discussion regarding the language regarding unknown ciphers.
> Please address that proposal (mine or Martin’s).
>
>
please don't exclude my proposal from consideration!   To summaries again:

   - Replace the current allowance for weak h1 ciphers with an explicit
   immutable white list of weak ciphers that can be used for h1 fallback.
   - Update text to say that block and stream ciphers are prohibited for
   h2, but that AEAD and future cipher classes are allowed.

The intent in these proposals is to leave no doubt in the servers
consideration of unknown ciphers. An offered cipher that is not in the h1
white list is h2 acceptable for the client. The server can then apply it's
own acceptability criteria without the need to guess what the client is
actually offering.

cheers

---

From: Jason Greene <[email-masked]>
Date: Thu, 25 Sep 2014 13:24:55 -0500

> If both parties both speak 1.3, 9.2.2 doesn’t apply, as per recent discussion.

The problem is you do not know whether or not the peer is 1.3 until after negotiation, and cipher suite restrictions are specified in advance, and you can’t restrict to 1.3 only if you intend to support h1 usage (or 1.2 h2 clients) on the same port. The best you could probably do is retry the connection with a 1.3 restriction enabled and the cipher restrictions dropped, which defeats the lightweight establishment benefit of H2.

> See recent discussion regarding the language regarding unknown ciphers. Please address that proposal (mine or Martin’s).

I was replying to Martin’s version. I was saying that the only way to meet that version of text is to either have a rich characteristics and priority API which isn’t prevalent today (see Michael Sweet’s most recent email), OR to hardcode the complete list (assuming the TLS stack allows a priority ordered list).

---

From: Julian Reschke <[email-masked]>
Date: Fri, 26 Sep 2014 09:03:46 +0200

> c) Change #2 above to “HTTP/2 MUST NOT be used with cipher suites that are known to be stream or block ciphers.” This emphasises that it’s a blacklist, not a whitelist, and avoids throwing INADEQUA…

Can we add a d), as suggested by yourself:

d) Constrain the http/2-on-tls constraints on ciper suites to TLS 1.2 only

(I didn't see any negative feedback on that idea)

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Sep 2014 09:08:54 +0100

> <http://http2.github.io/http2-spec/#rfc.section.9.2.2>

I've updated my pull request on this subject.  There are a few
editorial changes in the mix, but the commit log shows exactly what
changes are involved:

https://github.com/http2/http2-spec/pull/615

I believe that these changes resolve the issues people have raised.
That is, other than the one which states we shouldn't have this
section at all.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 26 Sep 2014 05:17:51 -0700

I think the lead-in paragraph (everything below only applies to TLS 1.2) is confusing when the first item after it then says "this isn't just limited to TLS 1.2".  Since all of the others are now explicitly TLS 1.2 requirements you can probably drop that lead-in paragraph to avoid the confusion...

And FWIW I still have no interoperable way to implement these restrictions in a client or server that supports both HTTP/1.1 and HTTP/2 with the current TLS libraries, so I'll have to use the sub-optimal negotiate-and-then-give-up-forcing-a-new-connection approach if I want to enforce the 9.2.2 cipher suite and minimum TLS version requirements.

> On Sep 26, 2014, at 1:08 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Jason Greene <[email-masked]>
Date: Fri, 26 Sep 2014 09:55:45 -0500

Has there been any discussion and buy-in with the major TLS implementers (OpenSSL, LibreSSL, Microsoft, NSS, etc) about the need to provide a characteristic-based priority and introspection API that also allows for different policies per TLS version? 

According to Michaels investigation it looks like all of them fall short of this. At a minimum we should at least have a commitment that a complete solution meeting the needs of future ciphers, legacy compatibility, and the rules of 9.2.2 will even be possible. While this still falls short of “working code”, there is at least a chance that it can be implemented without breaking standard industry usage patterns.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 26 Sep 2014 08:09:19 -0700

On Fri, Sep 26, 2014 at 7:55 AM, Jason Greene <[email-masked]>
wrote:

> Has there been any discussion and buy-in with the major TLS implementers
> (OpenSSL, LibreSSL, Microsoft, NSS, etc) about the need to provide a
> characteristic-based priority and introspection API that also allows for
> different policies per TLS version?
>
> According to Michaels investigation it looks like all of them fall short
> of this.

As I indicated previously, NSS provides the necessary introspection API.

http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2296.html

You don't need a priority API to correctly implement these requirements, nor
do you need one that provides differential requirements for different TLS
versions (other than the ones that are encoded in the TLS specifications
and implemented by the library).

-Ekr

> At a minimum we should at least have a commitment that a complete solution
> meeting the needs of future ciphers, legacy compatibility, and the rules of
> 9.2.2 will even be possible. While this still falls short of “working
> code”, there is at least a chance that it can be implemented without
> breaking standard industry usage patterns.
>
> > I think the lead-in paragraph (everything below only applies to TLS 1.2)
> is confusing when the first item after it then says "this isn't just
> limited to TLS 1.2".  Since all of the others are now explicitly TLS 1.2
> requirements you can probably drop that lead-in paragraph to avoid the
> confusion...
> >
> > And FWIW I still have no interoperable way to implement these
> restrictions in a client or server that supports both HTTP/1.1 and HTTP/2
> with the current TLS libraries, so I'll have to use the sub-optimal
> negotiate-and-then-give-up-forcing-a-new-connection approach if I want to
> enforce the 9.2.2 cipher suite and minimum TLS version requirements.
> >

---

From: Jason Greene <[email-masked]>
Date: Fri, 26 Sep 2014 10:32:28 -0500

On Sep 26, 2014, at 10:09 AM, Eric Rescorla <[email-masked]> wrote:

> 
> On Fri, Sep 26, 2014 at 7:55 AM, Jason Greene <[email-masked]> wrote:
> According to Michaels investigation it looks like all of them fall short of this.
> 

I saw that one, but it does not seem to allow me to say aead or anything stronger. Code written against this API would fail with aero for example. So we would need an AEAD+ like construct.  Today this is ok because AEAD is the latest. However, if a few months from now NSS adds it, the application will not be able to use it without a code update.

> and implemented by the library).

Here are the requirements we have assembled:

1. A TLS 1.2 connection without an ALPN for HTTP/2 can use any cipher allowed by TLS 1.2 that has not been blacklisted as a vulnerability
2. A TLS 1.2 connection with an ALPN for HTTP/2 can only use the subset of TLS 1.2 that 9.2.2 allows.
3. A TLS 1.3 (and later) connection can negotiate any cipher allowed by the spec

Further we have the existing common industry practice of separation of concerns, that an administrator can pick up new ciphers (and TLS versions), by simply updating a common TLS library on the system which is shared between application protocols (e.g. http stacks). While browsers have traditionally hard coded cipher suites, servers and other non-browser clients typically leave this to the TLS stack.

Do we agree on at least this? If so, how is an API I describe not necessary to meet all of this? Is there another way I have missed?

> 
> -Ekr
> 
>  
> At a minimum we should at least have a commitment that a complete solution meeting the needs of future ciphers, legacy compatibility, and the rules of 9.2.2 will even be possible. While this still falls short of “working code”, there is at least a chance that it can be implemented without breaking standard industry usage patterns.
>

---

From: Jason Greene <[email-masked]>
Date: Fri, 26 Sep 2014 10:39:13 -0500

> I saw that one, but it does not seem to allow me to say aead or anything stronger. Code written against this API would fail with aero for example. So we would need an AEAD+ like construct.  Today t…

Answering my own question on the introspection, that could work with !block && !stream as greg mentioned earlier.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 26 Sep 2014 09:13:23 -0700

Eric,

If you have a multi-protocol client that opportunistically uses HTTP/2 (which will likely be the case for a very long time for any web browser at least), then you can't simply require TLS/1.2 or omit non-HTTP/2 cipher suites from negotiation because that will cause existing HTTP/1.1 (and SPDY) servers to stop working if they don't support the specific TLS/1.2 ciphers or cannot negotiate TLS/1.2 at all.

So that leaves clients in the position of asking for h2 without HTTP/2 specific ciphers and then verifying the cipher suite and protocol version (>= TLS/1.2) are good after the session is established.

On the server side you are in a similar situation - if you are unable to influence the negotiation of cipher suites based on ALPN protocol (and I know I can't with any of the libraries I use, and only a few have a notion of preferred ciphers that might help in general) then you have to add "oops" code that tells the client to go away after the session is established with an unsupported cipher suite or protocol version.

We can't simply look at this as a "negotiating HTTP/2 over TLS" problem.  HTTP/2 has to interoperate with the existing web.

> On Sep 26, 2014, at 8:09 AM, Eric Rescorla <[email-masked]> wrote:
> 
>

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 27 Sep 2014 07:04:41 +1000

> I believe that these changes resolve the issues people have raised.

Those changes are indeed better, but they don't totally address my concerns
about the fragility of the handshake.

They do greatly reduce the probability that the handshake fragility will be
a problem, but only on the basis of assumptions of how the evolution of
TLS1.2 ciphers will progress, plus hope that any configurability of
ciphersuites will always be done in accordance with the principles of 9.2.2

Who is to say that a crypto emergency wont arise that requires the
deployment of TLS1.2 ciphers that are unknown for the purposes of the http2
implementation?     If cipher evolution does not pan out as expected and
deployers are forced to bend whatever rules they can with configuration,
then we still may have interoperability problems.

So while I don't oppose those changes, I still do not think they go far
enough as the handshake is still fragile - they just reduce the fragile
surface.

I think  that we either we need a handshake that clearly identifies the
break in the offered ciphers between acceptable and unacceptable.... or we
need an explicit white list of unacceptable h2 ciphers that may be offered
for h1 fallback.

regards

---

From: Willy Tarreau <[email-masked]>
Date: Sat, 27 Sep 2014 09:39:25 +0200

On Fri, Sep 26, 2014 at 09:13:23AM -0700, Michael Sweet wrote:
> Eric,
> 
> If you have a multi-protocol client that opportunistically uses HTTP/2 (which
> will likely be the case for a very long time for any web browser at least),
> then you can't simply require TLS/1.2 or omit non-HTTP/2 cipher suites from
> negotiation because that will cause existing HTTP/1.1 (and SPDY) servers to
> stop working if they don't support the specific TLS/1.2 ciphers or cannot
> negotiate TLS/1.2 at all.

I'm suddenly wondering about something : why is it that we have to support
different ciphers for H1 and H2 despite transporting the exact same contents ?
If some ciphers are not acceptable for H2, that makes me think they are at
risk for H1 as well, so shouldn't we say that if an agent wants to support
H1 as a fallback to H2 during a handshake, then it should only support the
ciphers that are compatible with both, even if this means the handshake
might fail on some old H1 servers (hence they'll have to retry with H1 only
and more ciphers). That would also probably speed up H2 adoption and clean up
of older ciphers.

Just my two cents,
Willy

---

From: "Martin Nilsson" <[email-masked]>
Date: Sat, 27 Sep 2014 17:58:41 +0200

On Fri, 26 Sep 2014 23:04:41 +0200, Greg Wilkins <[email-masked]> wrote:

> deployment of TLS1.2 ciphers that are unknown for the purposes of the  
> http2 >implementation?     If cipher evolution does not pan out as  
> expected and deployers are forced to bend whatever rules they can with  
> configuration, >then we still may have interoperability problems.

Do you believe we will intentionally release a new cipher that isn't  
strong enough to be acceptable for HTTP/2? If no, then there isn't a  
problem here.

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

---

From: Jason Greene <[email-masked]>
Date: Sat, 27 Sep 2014 11:34:58 -0500

On Sep 27, 2014, at 2:39 AM, Willy Tarreau <[email-masked]> wrote:

> risk for H1 as well,
> so shouldn't we say that if an agent wants to support
> and more ciphers).

It would break a large number of working H1-only clients just because the server the client is talking to also supports H2. The non-supported ciphers aren’t all bad they just aren’t state-of-art as of today.

---

From: Michael Sweet <[email-masked]>
Date: Sat, 27 Sep 2014 16:34:15 -0400

Willy,

> On Sep 27, 2014, at 3:39 AM, Willy Tarreau <[email-masked]> wrote:
> 

I suspect that someone deploying a H2 server will not want something that degrades the user experience of those using H1.  So I don't think that it will speed up H2 adoption - quite the opposite, in fact.

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 28 Sep 2014 12:12:08 +1000

> strong enough to be acceptable for HTTP/2? If no, then there isn't a

That is not the failure mode that we have been talking about.

It is not that the new keys are likely to be weak.  It is in fact because
they are almost certainly going to be strong, but might not match the 9.2.2
description of what a strong cipher is.

Repeated description of the issue follows... please skip if you have got it.

Once you have string keys that don't clearly fit the 9.2.2 description of
what string is,  then you get problems because the handshake is fragile and
depends on non ambiguous interpretation of 9.2.2 to work out which ciphers
are only there for h1 fallback.

If such new ciphers come along, implementations of 9.2.2 will need to be
revised and as those implementations are rolled out, we will have interop
failures because some servers will wrongly assume that a new strong 9.2.2
dubious cipher is being offered for h2 by an updated client when it is in
fact being offered as a h1 fallback cipher.

Ie are we 100% certain that all future strong ciphers will pass:
isEphemeral() && !isBlock() && !isStream()?    What about the alternate
implementation of this that we have seen in FF of isEphemeral() && isAEAD()
- will that be true for all strong ciphers for the life of h2?

Nobody has yet said why we cannot just make the handshake non-fragile.
I've offered several suggestion for that:
 a) white list of know h1 fallback ciphers
 b) update ALPN to indicate which ciphers are acceptable for each offered
protocol
 c) do a h1 only retry handshake
 d) move the  9.2.2 requirement that applies equally to h1 and h2

---

From: "Martin Nilsson" <[email-masked]>
Date: Sun, 28 Sep 2014 19:53:21 +0200

On Sun, 28 Sep 2014 04:12:08 +0200, Greg Wilkins <[email-masked]> wrote:

>> problem >>here.
> It is not that the new keys are likely to be weak.  It is in fact  
> because they are almost certainly going to be strong, but might not  
> match the 9.2.2 >description of what a strong cipher is.

Either a new cipher will match the 9.2.2 criteria of strong key, and there  
is no problem, or it does not match, we state in text that it is also  
allowed for http/2, and there is no problem.

/Martin Nilsson

-- 
Using Opera's mail client: http://www.opera.com/mail/