Subject: #612: 9.2.2 requirements

From: Mark Nottingham <[email-masked]>
Date: Mon, 27 Oct 2014 13:54:03 -0700

<https://github.com/http2/http2-spec/issues/612>

Reviewing the discussion, I think it’s going to be difficult to declare consensus on 9.2.2 in its current form.

Talking through it with a few of the proponents, my proposal to close this issue is to remove 9.2.2 (i.e., the specific requirements on cipher suites), but leave 9.2.1 (the section on TLS features) as-is.

Thoughts?

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

---

From: Mike Bishop <[email-masked]>
Date: Mon, 27 Oct 2014 21:15:21 +0000

+1

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Monday, October 27, 2014 1:54 PM
To: HTTP Working Group
Subject: #612: 9.2.2 requirements

Thoughts?

---

From: Mike Sweet <[email-masked]>
Date: Mon, 27 Oct 2014 17:32:38 -0400

+1

Sent from my iPhone

> On Oct 27, 2014, at 4:54 PM, Mark Nottingham <[email-masked]> wrote:
>

---

From: Jason Greene <[email-masked]>
Date: Mon, 27 Oct 2014 16:36:26 -0500

> On Oct 27, 2014, at 3:54 PM, Mark Nottingham <[email-masked]> wrote:
> 

Sounds good.

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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Oct 2014 15:53:18 -0700

> Talking through it with a few of the proponents, my proposal to close this issue is to remove 9.2.2 (i.e., the specific requirements on cipher suites), but leave 9.2.1 (the section on TLS features)…

Unless this gets significant push-back.
https://github.com/http2/http2-spec/pull/638

---

From: Patrick McManus <[email-masked]>
Date: Mon, 27 Oct 2014 21:39:23 -0400

> Thoughts?

poodle is direct evidence that algorithms that are necessary for interop
simply don't get deprecated in the field even when they are superceded..
Requiring current best practices at least makes a clean break for h2 which
doesn't have the interop baggage. Half measures are an un-necessarily weak
effort.

This is exacerbated by the previous decision to move from NPN to ALPN - a
client interested in restricting h2 to newer security suites can no longer
effectively do so as the server is allowed to choose old (perhaps h1
suitable suites) along with h2. That problem would not be symmetrical for a
server with NPN wishing to enforce a higher level of security as it still
selects the cipher suite. Brian provided convincing reasoning previously on
why a peer would want to do so.

we can do better.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 28 Oct 2014 15:33:25 +0200

> On Oct 27, 2014, at 10:54 PM, Mark Nottingham <[email-masked]> wrote:
> 

I’m rather surprised this is the outcome, but +1

Yoav

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Oct 2014 20:41:33 +0200

> doesn't have the interop baggage. Half measures are an un-necessarily weak

Unfortunately, H2 does have interop baggage. If it ran on its own port,
instead of sharing one with H1, it didn't, but sharing port means interop
baggage.

Now, if TLS stacks were capable enough, one could do all sorts of things,
but with things the way are now, I don't see anything beyond setting
TLS 1.2 minimum (as is done) as doable.

And to me, POODLE was a painful demonstration that unauthenticated fallbacks
are a bad idea.

Oh, and when TLS 1.3 comes out, there will be more fun about that: SSL 3.0
key exchange is quite bad, and it isn't until TLS 1.3 where they really
fix things. So TLS 1.2 pretty much shares the bad SSL 3.0 key exchange.

As for pushing better algorithms, that would be mostly in H1. I really don't
think that SHA-1 in EE certificates is the most pressing security problem in
H1 over TLS (CA certificates are another matter).

> why a peer would want to do so.

ALPN has some limitations compared to NPN, yes.

-Ilari

---

From: Brian Smith <[email-masked]>
Date: Tue, 28 Oct 2014 14:23:20 -0700

Mark Nottingham <[email-masked]> wrote:

> Talking through it with a few of the proponents, my proposal to close this
> issue is to remove 9.2.2 (i.e., the specific requirements on cipher
> suites), but leave 9.2.1 (the section on TLS features) as-is.
>
> Thoughts?
>

What is the actual diff? 9.2.2 cannot be removed reasonably without adding
new text to the security considerations section, but AFAICT nobody has
written the new security considerations section yet. In particular, how do
the known attacks on TLS configurations forbidden by 9.2.2 affect HTTP/2?

I find it difficult to tell what arguments against the 9.2.2 requirements
have not been sufficiently refuted. I read the arguments against the 9.2.2
requirements carefully because I wanted to try to help address them in a
constructive way that accomplishes the goal of improving security without
causing an unnecessary burden for anybody, but I've not been able to figure
out what is actually unreasonably burdensome about the 9.2.2 requirements.

This issue in particular seems like one where "Rough consensus is achieved
when all issues are addressed, but not necessarily accommodated" from RFC
7282 applies.

Finally, didn't Google say that they're still going to apply the 9.2.2
restrictions even if 9.2.2 is removed from the spec? And, maybe Mozilla
will do the same thing? If so, then wouldn't removing 9.2.2 cause
significant problems due to the fact that the requirements in the document
aren't sufficient to describe how to interoperate?

Cheers,
Brian

---

From: Jason Greene <[email-masked]>
Date: Tue, 28 Oct 2014 17:11:22 -0500

> On Oct 28, 2014, at 4:23 PM, Brian Smith <[email-masked]> wrote:
> 
> I find it difficult to tell what arguments against the 9.2.2 requirements have not been sufficiently refuted. I read the arguments against the 9.2.2 requirements carefully because I wanted to try to help address them in a constructive way that accomplishes the goal of improving security without causing an unnecessary burden for anybody, but I've not been able to figure out what is actually unreasonably burdensome about the 9.2.2 requirements.

The handshake issues have not been refuted. Here is an example:
http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0167.html

I summarized the only solutions that I am aware of and they are either burdensome, or not widely available. All are arguably error-prone.

http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0198.html

There is also a compelling argument that this is not the proper place to mandate TLS framework API behavior, which is indirectly required to achieve these rules and avoid the resulting negotiation issues:

http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0114.html

---

From: Martin Thomson <[email-masked]>
Date: Tue, 28 Oct 2014 16:20:53 -0700

> the known attacks on TLS configurations forbidden by 9.2.2 affect HTTP/2?

I'm not aware of specific security considerations that need to be
written in this context regarding 9.2.2.  The security analysis hasn't
assumed anything about the cipher suite selection (the only potential
loss here).  The analysis relies only on the stuff in 9.2.1 (no
compression, no renegotiation), which we are keeping.

---

From: Roland Zink <[email-masked]>
Date: Wed, 29 Oct 2014 10:01:26 +0100

+1

I think the cipher suites are better handled by TLS and this avoids 
potential problems with ALPN.

Regards,
Roland

---

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

I'm +1 on this.

I think it is good to remove explicit cipher restrictions from this
document, but my primary concern has always been the fragile handshake,
which I think we still have if INADEQUATE_SECURITY is sent.

It is good that we are removing explicit cipher restrictions from this
document as I don't think they belong in an application protocol.  But we
are still allowing implementations to discriminate on the basis of TLS
features by sending an INADEQUATE_SECURITY error, which may then still
result in handshake failure even if there are mutually acceptable
cipher/protocol combinations.

There are definitely many voices here that would like to enforce higher TLS
standards for h2 than h1 and the INADEQUATE_SECURITY error is a mechanism
that remains available for them to do that.  I think that implementations
and/or deployments should be able to impose higher standards without
risking handshake failure, thus I think we still need to make the handshake
more robust in the case of INADEQUATE_SECURITY, - with SHOULD level
requirements about retries and/or h1 fallback.

But If we really cannot guarantee handshake success if an
INADEQUATE_SECURITY is sent (and there are mutually acceptable
cipher/protocol combinations), then we should remove that error code and
put all the security responsibility entirely on the TLS implementation.

regards

On 29 October 2014 20:01, Roland Zink <[email-masked]> wrote:

>> Talking through it with a few of the proponents, my proposal to close
>> this issue is to remove 9.2.2 (i.e., the specific requirements on cipher

-- 
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: Nicholas Hurley <[email-masked]>
Date: Wed, 29 Oct 2014 16:11:13 -0700

+1 on everything Patrick has said. Removing 9.2.2 just brings us back to
the same old (pretty nasty) TLS situation we have now, and just because
it might be hard doesn't mean we shouldn't do the right thing in pushing
the bar higher.

On Mon, Oct 27, 2014, at 18:39, Patrick McManus wrote:
> poodle is direct evidence that algorithms that are necessary for
> interop simply don't get deprecated in the field even when they are
> superceded.. Requiring current best practices at least makes a clean
> break for h2 which doesn't have the interop baggage. Half measures are
> an un-necessarily weak effort.
>
> This is exacerbated by the previous decision to move from NPN to ALPN
> - a client interested in restricting h2 to newer security suites can
> no longer effectively do so as the server is allowed to choose old
> (perhaps h1 suitable suites) along with h2. That problem would not be
> symmetrical for a server with NPN wishing to enforce a higher level of
> security as it still selects the cipher suite. Brian provided
> convincing reasoning previously on why a peer would want to do so.
>
> we can do better.
>
>
>
>

--
Peace, -Nick

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 30 Oct 2014 14:30:23 +1300

On 30/10/2014 12:11 p.m., Nicholas Hurley wrote:
> 
> +1 on everything Patrick has said. Removing 9.2.2 just brings us
> back to the same old (pretty nasty) TLS situation we have now, and
> just because it might be hard doesn't mean we shouldn't do the
> right thing in pushing the bar higher.

Things are not quite _that_ bad.

SSL/*, TLS/1.0 and TLS/1.1 are prohibited for use with HTTP/2. Which
is still a large step forward in security.

Quest for perfection killing the benefit was what 9.2.2 did.

Amos

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 1 Nov 2014 05:35:07 +1100

> On 27 Oct 2014, at 1:54 pm, Mark Nottingham <[email-masked]> wrote:
> 

And yet, I get the big bucks* from the IESG to do the difficult things. Winning a straw poll is not necessarily consensus in the IETF.

> Talking through it with a few of the proponents, my proposal to close this issue is to remove 9.2.2 (i.e., the specific requirements on cipher suites), but leave 9.2.1 (the section on TLS features)…

Talking it through at length with our Area Director and other IETF leadership, this will not fly (at least that easily). 

The fundamental technical issue — publishing a protocol standard that allows cipher suites that we know to be insecure — has not been addressed. Patrick is absolutely right about this. 

The question at hand is what interoperability cost is involved in 9.2.2. If it is a cost paid by a few implementations who don’t have adequate APIs immediately at hand, that is emphatically *not* a technical issue. 

If it were a considerable interoperability cost to the whole community — i.e., it caused long-term problems across most or all deployments of the new protocol — it would be serious enough to warrant consideration. 

So far, this does not seem to be the case; a significant number of browser vendors have said that they will not fall back to HTTP/1.1 if they see servers that cause them to throw INADEQUATE_SECURITY, thereby isolating those servers that are not conformant (and giving them a *very* strong incentive to become conformant). Even if they were to retry, it would not be an interoperability issue; only a performance degradation for non-conformant servers.

In other words, while 9.2.2 may retard deployment of the new protocol while some implementations are updated to support it, it does not seem to put the entire effort at risk of interoperability problems.

The arguments that this is a process or layering issue are not valid; both have been refuted.

While some may consider the handshake “fragile”, they’ll need to explain how — given the above context — it affects interoperability in a way that’s significant. So far, I haven’t seen an explanation of how the handshake raises such an issue.

If you think you have one, please carefully explain it to us (even if you have before — and thank you for your patience) soon. Without more (and convincing) information, we don’t have adequate reason to remove 9.2.2 from the specification, and therefore I think that the resolution that gets us to consensus on #612 is Martin’s first pull request:

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

Sorry for the back-and-forth; it’s important to get this right.

Regards,

* If I’m really lucky, Barry will buy me a drink in HNL.

---

From: Jason Greene <[email-masked]>
Date: Fri, 31 Oct 2014 14:42:22 -0500

> On Oct 31, 2014, at 1:35 PM, Mark Nottingham <[email-masked]> wrote:
> 

They are not insecure, just not modern. There is a huge difference. If they were insecure, you wouldn’t be able to use them with H1 today and TLS 1.2 today, they would be blacklisted.

> The question at hand is what interoperability cost is involved in 9.2.2. If it is a cost paid by a few implementations who don’t have adequate APIs immediately at hand, that is emphatically *not* a…

AFAIK there is exactly *one* TLS implementation out there that has nearly adequate facilities, NSS.

> So far, this does not seem to be the case; a significant number of browser vendors have said that they will not fall back to HTTP/1.1 if they see servers that cause them to throw INADEQUATE_SECURIT…

Thats not true, the problem can occur with a conforming implementation.

> The arguments that this is a process or layering issue are not valid; both have been refuted.

It would be great to hear the refutation to Microsoft’s position that the UTA is more appropriate for mandating TLS implementation API enhancements, and not the HTTP WG:

> If you think you have one, please carefully explain it to us (even if you have before — and thank you for your patience) soon. Without more (and convincing) information,

Ilari’s use case is a great example of where it all goes wrong:
http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0167.html

I summarized the only known non-fragile handshaking solutions here:
http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0198.html

> we don’t have adequate reason to remove 9.2.2 from the specification, and therefore I think that the resolution that gets us to consensus on #612 is Martin’s first pull request:
> 

Agreed. It’s not unsolvable.

---

From: Brian Smith <[email-masked]>
Date: Fri, 31 Oct 2014 14:05:06 -0700

Jason Greene <[email-masked]> wrote:

> > The question at hand is what interoperability cost is involved in 9.2.2.
> If it is a cost paid by a few implementations who don’t have adequate APIs
> immediately at hand, that is emphatically *not* a technical issue.
>

If NSS's facilities are adequate, then that is a very good sign for other
implementations, because NSS's facilities for this are very simple, were
very simple to implement, and were deployed without any (AFAIK) disruption
to any production systems.

He wrote, in part:

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

First of all, it is almost always going to be a bad idea to have the server
TLS stack choose which application protocol to use. Instead, it should
defer that choice to the server application. Second of all, if the server
doesn't take that advice, and the TLS stack has already chosen h2, then the
HTTP/2 layer might as well keep going on the assumption that XYZ is OK,
because it hasn't given itself any better choice, due to not taking that
advice. If things don't work, the server administrator will likely fix it
by improving the cipher suite configuration, probably by reading section
9.2.2 of the specification or documentation derived from it. Of course,
it's better for the server software implementation to just automatically do
the right thing, but that's a quality-of-implementation issue, not a
protocol issue.

Cheers, Brian

---

From: Patrick McManus <[email-masked]>
Date: Fri, 31 Oct 2014 17:14:29 -0400

> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0167.html

I believe that just describes an API limitation, not a protocol problem. A
hypothetical implementation directly participated in the negotiation of XYZ
and h2 but for whatever reason cannot ensure the relevant properties of XYZ
with respect to h2's application profile of tls laid out in 9.2.

-Patrick

---

From: Jason Greene <[email-masked]>
Date: Fri, 31 Oct 2014 16:53:13 -0500

> On Oct 31, 2014, at 4:14 PM, Patrick McManus <[email-masked]> wrote:
> 
> 
> On Fri, Oct 31, 2014 at 3:42 PM, Jason Greene <[email-masked]> wrote:
> 
> I believe that just describes an API limitation, not a protocol problem. A hypothetical implementation directly participated in the negotiation of XYZ and h2 but for whatever reason cannot ensure the relevant properties of XYZ with respect to h2's application profile of tls laid out in 9.2.

It’s fundamentally a protocol issue, and the API requirements are, in fact, created to work around this protocol problem. Both ends of the TLS connection have a vested interest in supporting legacy ciphers on legacy protocols, and so it will be common that clients will offer ciphers they do not support with H2, and servers will accept ciphers that are not supported with H2, since both H1 and H2 share the same underlying TCP port.

In order to fix the protocol problem you need a way to associate the cipher suites with the application protocol. The only facility in the TLS handshake, as it defined today, that can accomplish that, is the TLS protocol version. If H2 required TLS 1.3, these problems would not occur. 

The requirements in 9.2.2 try to achieve similar behavior to the more accurate TLS 1.3 restriction, by mandating that H2 stacks needlessly duplicate TLS rules after cipher selection has already been made, thus leading to possible errors. Further even if the H2 stack gets it right, it’s common industry practice to update TLS libraries independent of the H2 stack leading to the H2 stack having older inaccurate rules (version-skew).

---

From: Michael Sweet <[email-masked]>
Date: Fri, 31 Oct 2014 18:10:06 -0400

Mark,

> On Oct 31, 2014, at 2:35 PM, Mark Nottingham <[email-masked]> wrote:
> ...

First, TLS does not provide a way to tie cipher suite selection to ALPN.  That makes it impossible for a client or server to restrict their ciphers without deciding ahead of time to first try only HTTP/2-compatible cipher suites and, when that fails, re-try a HTTP/1.x only connection.  I think that counts as a technical issue, and definitely a performance issue that will only hurt adoption of HTTP/2 or force UAs to try two connections in parallel to avoid the HTTP/1 penalty.

Second, you cannot dismiss the inadequate API issue.  Currently only OpenSSL and GNU TLS offer APIs to select cipher suites based on general capabilities, and even they are not sufficient to match all of 9.2.2's current restrictions.  For SSP on Windows and SecureTransport on iOS and OS X, you have to either hardcode a list of known cipher suite constants or try to write a blacklist by querying the supported cipher suites and removing those that are known not to be acceptable.  On top of that is a known bug in SecureTransport that prevents you from actually using the API to set the enabled cipher suites... :/  None of the common TLS libraries provide a way to ask what the security properties of a particular cipher suite are, so it is impossible to programmatically support 9.2.2 and support new cipher suites without a code change in the application layer.

> If it were a considerable interoperability cost to the whole community — i.e., it caused long-term problems across most or all deployments of the new protocol — it would be serious enough to warran…

There are already issues with the lack of ALPN support (that are slowly being addressed), and I (and others) have brought up the lack of support for restricting the allowed ciphers for HTTP/2, for which there is no technical solution (ALPN doesn't support it) aside from the server or client giving up on the connection after a successful TLS negotiation with the wrong cipher suite.

> So far, this does not seem to be the case; a significant number of browser vendors have said that they will not fall back to HTTP/1.1 if they see servers that cause them to throw INADEQUATE_SECURIT…

The problem is worse - the client software may support HTTP/2 while the server only supports HTTP/1.  Since it is likely that the negotiated connection will not be for TLS/1.2, how can a client possibly limit its set of cipher suites to those that are compliant with 9.2.2?  And then the server that still has to support HTTP/1 clients and older versions of TLS also cannot limit its set of cipher suites.  And since NO TLS library seems to support the notion of cipher suite ordering (at least none are documented to), and since ALPN has no way to specify acceptable cipher suites for h2, we *will* have otherwise conforming implementations needing to send INADEQUATE_SECURITY because the underlying TLS libraries are unable to support the HTTP/2 restrictions AND still allow HTTP/1 traffic.

> ...

No, they haven't.  I've documented the issues that make deploying HTTP/2 along side HTTP/1 impossible, and nobody has refuted my findings (quite the opposite).

> While some may consider the handshake “fragile”, they’ll need to explain how — given the above context — it affects interoperability in a way that’s significant. So far, I haven’t seen an explanati…

See above.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Jason Greene <[email-masked]>
Date: Fri, 31 Oct 2014 17:21:06 -0500

> On Oct 31, 2014, at 4:05 PM, Brian Smith <[email-masked]> wrote:
> 
> If NSS's facilities are adequate, then that is a very good sign for other implementations, because NSS's facilities for this are very simple, were very simple to implement, and were deployed without any (AFAIK) disruption to any production systems.

It’s close, but I think its still missing the ability to actually influence the handshake, which would require characteristic based priority ordering (or alternatively large white lists that hopefully match). Hey if its easy for all of them to address this problem, thats great, but IMO we should be asking them, not just assuming it will occur. 

> First of all, it is almost always going to be a bad idea to have the server TLS stack choose which application protocol to use.
> Instead, it should defer that choice to the server application.

That doesn’t help because the problem is the cipher selection happens independently of all of that (handshake precedes the ALPN selection), and its shared between H2 and H1 support thats the issue.

> Second of all, if the server doesn't take that advice, and the TLS stack has already chosen h2, then the HTTP/2 layer might as well keep going on the assumption that XYZ is OK, because it hasn't given itself any better choice, due to not taking that advice. I

Since it does not know that XYZ is allowed by 9.2.2 it has no choice but to reject. Without a proper protocol negotiation the H2 implementation is required to either have in-synch consistency with the TLS stack (and also consistency with the peer TLS & H2 stack), or it needs the ability to ask and influence the TLS stack as part of the TLS stacks handshake, using some simpler set of rules.

> f things don't work, the server administrator will likely fix it by improving the cipher suite configuration, probably by reading section 9.2.2 of the specification or documentation derived from it. Of course, it's better for the server software implementation to just automatically do the right thing,

Yes the best course of action will be for the administrator to add XYZ in the configuration. However, if a server implementer simply ignored 9.2.2, XYZ would have succeeded, without user intervention, leading to better security and performance. Until the proper TLS APIs exist (I’m not holding my breath), or TLS 1.3 occurs, this is the best action an implementer can take.

---

From: Brian Smith <[email-masked]>
Date: Fri, 31 Oct 2014 15:52:11 -0700

Jason Greene <[email-masked]> wrote:

> > Brian Smith <[email-masked]> wrote:
> > > The question at hand is what interoperability cost is involved in
> 9.2.2. If it is a cost paid by a few implementations who don’t have
> adequate APIs immediately at hand, that is emphatically *not* a technical
> issue.
> >
> > If NSS's facilities are adequate, then that is a very good sign for
> other implementations, because NSS's facilities for this are very simple,
> were very simple to implement, and were deployed without any (AFAIK)
> disruption to any production systems.
>
> It’s close, but I think its still missing the ability to actually
> influence the handshake, which would require characteristic based priority
> ordering (or alternatively large white lists that hopefully match). Hey if
> its easy for all of them to address this problem, thats great, but IMO we
> should be asking them, not just assuming it will occur.
>

The TLS implementation should be configured to always prefer
9.2.2-compliant cipher suites over non-9.2.2 compliant cipher suites,
regardless of which application protocol is negotiated. Or, at least that
should be the case when the TLS implementation doesn't offer a mechanism to
choose the cipher suite based on the application protocol.

> > First of all, it is almost always going to be a bad idea to have the
> server TLS stack choose which application protocol to use.
> That doesn’t help because the problem is the cipher selection happens
> independently of all of that (handshake precedes the ALPN selection), and
> its shared between H2 and H1 support thats the issue.
>

The handshake does not precede ALPN selection. With ALPN, the ServerHello
message contains the chosen protocol, and ServerHello is the first message
the server sends. The TLS implementation cannot send even the initial bytes
of the ServerHello message without knowing the chosen protocol because the
length is encoded at the start of the message, and the length is dependent
on the protocol chosen. If the TLS implementation provides a mechanism for
the application layer to choose a cipher suite based on the protocol, then
it needs to ask the application for the protocol before it chooses a cipher
suite. Otherwise, like I said before, it should always just choose an
9.2.2-compliant cipher suite.

> Second of all, if the server doesn't take that advice, and the TLS stack
> has already chosen h2, then the HTTP/2 layer might as well keep going on
> the assumption that XYZ is OK, because it hasn't given itself any better
> choice, due to not taking that advice. I
>
> Since it does not know that XYZ is allowed by 9.2.2 it has no choice but
> to reject. Without a proper protocol negotiation the H2 implementation is
> required to either have in-synch consistency with the TLS stack (and also
> consistency with the peer TLS & H2 stack), or it needs the ability to ask
> and influence the TLS stack as part of the TLS stacks handshake, using some
> simpler set of rules.
>

No, it doesn't have to reject XYZ. It can carry on based on the assumption
that XYZ is OK. If it is, then the client will accept it. If it isn't, the
client will return INSUFFICIENT_SECURITY to the server. (Keep in mind that
this is only in the worse case where the server's HTTP/2 implementation is
based on a TLS stack that is too inflexible to do better things.)

> > f things don't work, the server administrator will likely fix it by
> improving the cipher suite configuration, probably by reading section 9.2.2
> of the specification or documentation derived from it. Of course, it's
> better for the server software implementation to just automatically do the
> right thing,
>
> Yes the best course of action will be for the administrator to add XYZ in
> the configuration. However, if a server implementer simply ignored 9.2.2,
> XYZ would have succeeded, without user intervention, leading to better
> security and performance. Until the proper TLS APIs exist (I’m not holding
> my breath), or TLS 1.3 occurs, this is the best action an implementer can
> take.
>

Like I said above, if the server HTTP/2 implementation is in the
unfortunate situation where it has no choice but to accept the cipher suite
and protocol that the TLS implementation chose, and it has no way of
learning the relevant properties of the unknown cipher suite XYZ, then it
should assume that XYZ is valid as far as 9.2.2 is concerned and rely on
the client to reject it, in the absence of better information.

However, again, this can only occur when the server software stack is
designed in the worst possible way that could possibly work AND when the
server software is configured poorly. Luckily, it is easy to change TLS
stacks and HTTP stacks to use a better design, and it is possible (perhaps
not so easy) to design things in a way that helps server administrators
migrate to good cipher suite configurations.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Fri, 31 Oct 2014 16:00:55 -0700

Jason Greene <[email-masked]> wrote:

> Until the proper TLS APIs exist (I’m not holding my breath), or TLS 1.3
> occurs, this is the best action an implementer can take.

Also, this working group decided a long time ago that it is reasonable to
require TLS implementations to be changed to support HTTP/2. In fact, this
working group actually required *every* TLS implementation to be changed to
support ALPN, even though many of them would have worked fine, unmodified,
with the NPN support that they already had. So, the argument that changes
to TLS implementations may need to be modified has already been decided to
be invalid.

Cheers,
Brian

---

From: Brian Smith <[email-masked]>
Date: Fri, 31 Oct 2014 16:11:43 -0700

Michael Sweet <[email-masked]> wrote:

> First, TLS does not provide a way to tie cipher suite selection to ALPN.

Sure it does. It is easy to see how a TLS implementation could be designed
such that it associates every ALPN protocol with a different set of cipher
suites and then chooses a cipher suite based on that information, even
before, during, or after it decides which protocol to advertise with ALPN

> That makes it impossible for a client or server to restrict their ciphers
> without deciding ahead of time to first try only HTTP/2-compatible cipher
> suites and, when that fails, re-try a HTTP/1.x only connection.  I think
> that counts as a technical issue, and definitely a performance issue that
> will only hurt adoption of HTTP/2 or force UAs to try two connections in
> parallel to avoid the HTTP/1 penalty.
>

There are already implementations doing the thing that you call impossible,
so it is clearly not impossible.

> Second, you cannot dismiss the inadequate API issue.  Currently only
> OpenSSL and GNU TLS offer APIs to select cipher suites based on general
> capabilities, and even they are not sufficient to match all of 9.2.2's
> current restrictions.  For SSP on Windows and SecureTransport on iOS and OS
> X, you have to either hardcode a list of known cipher suite constants or
> try to write a blacklist by querying the supported cipher suites and
> removing those that are known not to be acceptable.  On top of that is a
> known bug in SecureTransport that prevents you from actually using the API
> to set the enabled cipher suites... :/  None of the common TLS libraries
> provide a way to ask what the security properties of a particular cipher
> suite are, so it is impossible to programmatically support 9.2.2 and
> support new cipher suites without a code change in the application layer.
>

Those are *all* implementation issues that can easily be fixed. Also, keep
in mind that the HTTP/2 implementation can choose to use a different TLS
stack that is more capable and/or easier to modify. In particular, you're
not forced to use SecureTransport or SSP. Also, I see no reason to think
that it is impossible to modify SecureTransport or SSP to have the
additional capabilities in a way that is backward-compatible and
non-disruptive to existing applications.

Cheers,
Brian

---

From: Michael Sweet <[email-masked]>
Date: Fri, 31 Oct 2014 20:09:02 -0400

Brian,

> On Oct 31, 2014, at 7:11 PM, Brian Smith <[email-masked]> wrote:
> 
> Sure it does. It is easy to see how a TLS implementation could be designed such that it associates every ALPN protocol with a different set of cipher suites and then chooses a cipher suite based on that information, even before, during, or after it decides which protocol to advertise with ALPN 

Sigh. No implementation exists to offer that feature set, and the ALPN negotiation doesn't have information on what a particular protocol needs. And worse, there are already multiple protocols that a browser might negotiate, with different cipher suite requirements!

>> That makes it impossible for a client or server to restrict their ciphers without deciding ahead of time to first try only HTTP/2-compatible cipher suites and, when that fails, re-try a HTTP/1.x only connection.  I think that counts as a technical issue, and definitely a performance issue that will only hurt adoption of HTTP/2 or force UAs to try two connections in parallel to avoid the HTTP/1 penalty.
> 
> There are already implementations doing the thing that you call impossible, so it is clearly not impossible.

We have limited deployment of implementations that use their own crypto toolkits, or that only support http/2 and its cipher suites. And a bunch of work in progress prototypes whose developers have been complaining about these requirements from day one because their own toolkits are not capable of supporting both http/1 and http/2 TLS requirements.
 
> Those are *all* implementation issues that can easily be fixed. Also, keep in mind that the HTTP/2 implementation can choose to use a different TLS stack that is more capable and/or easier to modify. In particular, you're not forced to use SecureTransport or SSP.

You do if you want to ship applications for a particular OS and support the OS supplied TLS policies.

> Also, I see no reason to think that it is impossible to modify SecureTransport or SSP to have the additional capabilities in a way that is backward-compatible and non-disruptive to existing applications.

The point is that they cannot support HTTP/2 today with these restrictions, not that we can't make arbitrary API to support an arbitrary and questionable line in the sand that has obvious interop issues with today's web. HTTP/1 will be around for a very long time yet, so intentionally adding barriers to HTTP/2 adoption seems short sighted. You're trying to mandate security in a way that causes interoperability problems, and conformance requirements are supposed to work the other way (I.e., improve interoperability)

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Oct 2014 19:11:02 -0700

On 31 October 2014 15:52, Brian Smith <[email-masked]> wrote:
> The TLS implementation should be configured to always prefer 9.2.2-compliant
> cipher suites over non-9.2.2 compliant cipher suites, regardless of which
> application protocol is negotiated. Or, at least that should be the case
> when the TLS implementation doesn't offer a mechanism to choose the cipher
> suite based on the application protocol.

You only have to ensure that 9.2.2-compliant suites are preferred up
until the MTI suite, so it's not even that hard.

As it happens, the order you chose for the suites in NSS places that
second (the first is the same with an ECDSA cert - less widely
deployed, but faster and more secure generally).  After that, the
order doesn't matter much.

---

From: Jason Greene <[email-masked]>
Date: Fri, 31 Oct 2014 22:49:23 -0500

> On Oct 31, 2014, at 5:52 PM, Brian Smith <[email-masked]> wrote:
> The handshake does not precede ALPN selection. With ALPN, the ServerHello message contains the chosen protocol, and ServerHello is the first message the server sends. The TLS implementation cannot send even the initial bytes of the ServerHello message without knowing the chosen protocol because the length is encoded at the start of the message, and the length is dependent on the protocol chosen. If the TLS implementation provides a mechanism for the application layer to choose a cipher suite based on the protocol, then it needs to ask the application for the protocol before it chooses a cipher suite. Otherwise, like I said before, it should always just choose an 9.2.2-compliant cipher suite.

My point is that a legacy compatible client advertises cipher suites that aren’t compatible with H2 before H2 is selected. This is in contrast to a 1.3 client that would advertise 1.3 ciphers, and use SCSV fallback for pre 1.3 ciphers, which is a much more robust handshake, and leaves the TLS cipher selection where it belongs. 

I am not arguing that a TLS implementation could not provide an API that allowed selection of cipher suites based on ALPN selection. Thats just another variant of the nonexistant-api-with-no-known-plans-to-exist category.

> No, it doesn't have to reject XYZ. It can carry on based on the assumption that XYZ is OK. If it is, then the client will accept it. If it isn't, the client will return INSUFFICIENT_SECURITY to the server. (Keep in mind that this is only in the worse case where the server's HTTP/2 implementation is based on a TLS stack that is too inflexible to do better things.)

But that would violate 9.2.2 which clearly refers to both parties. I agree that it would be better if the language where changed to say that the client MUST and the server SHOULD, and would be in favor of that change. That would certainly address the interop issue, but it would still leave the possibility that an h2 client would exclude stronger ciphers than the TLS implementation supports, since the h2 stack may not yet be aware of them.

> Like I said above, if the server HTTP/2 implementation is in the unfortunate situation where it has no choice but to accept the cipher suite and protocol that the TLS implementation chose, and it has no way of learning the relevant properties of the unknown cipher suite XYZ, then it should assume that XYZ is valid as far as 9.2.2 is concerned and rely on the client to reject it, in the absence of better information.
> 
> However, again, this can only occur when the server software stack is designed in the worst possible way that could possibly work AND when the server software is configured poorly. Luckily, it is easy to change TLS stacks and HTTP stacks to use a better design, and it is possible (perhaps not so easy) to design things in a way that helps server administrators migrate to good cipher suite configurations.
> 

Sure, when and if everything is updated the issues go away. However the reality is the h2 spec is about to go final, and I don’t see everyone waiting around for this to all happen before they ship their implementations. What will happen is either implementations won’t bother to implement it, or they will try to make it work with what exists today, which is as you say “the worst possible way it could work”, and it will likely lead to interop issues. That is assuming 9.2.2 continues as is, with none of the possible fixes (including the server softening fix above).

---

From: Jason Greene <[email-masked]>
Date: Fri, 31 Oct 2014 22:51:44 -0500

> On Oct 31, 2014, at 6:00 PM, Brian Smith <[email-masked]> wrote:
> 
>> Until the proper TLS APIs exist (I’m not holding my breath), or TLS 1.3 occurs, this is the best action an implementer can take.
>> 
> Also, this working group decided a long time ago that it is reasonable to require TLS implementations to be changed to support HTTP/2. In fact, this working group actually required *every* TLS implementation to be changed to support ALPN, even though many of them would have worked fine, unmodified, with the NPN support that they already had. So, the argument that changes to TLS implementations may need to be modified has already been decided to be invalid.

I don’t think that situation is comparable because ALPN was discussed and favored by the TLS WG.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 31 Oct 2014 21:09:17 -0700

> My point is that a legacy compatible client advertises cipher suites that aren’t compatible with H2 before H2 is selected. This is in contrast to a 1.3 client that would advertise 1.3 ciphers, and…

That's not right.  A 1.3 client will offer cipher suites that are only
supported in 1.2 and earlier because a round-trip is a high price to
pay for guessing wrong.  What you suggest would basically prevent 1.3
from ever being deployed.

The 1.3 handshake will be compatible with all 1.2 and earlier servers
(assuming that they are not version or extension intolerant...i.e.,
not broken).