Subject: 9.2.2 Cipher fallback and FF<->Jetty interop problem

From: Greg Wilkins <[email-masked]>
Date: Fri, 5 Sep 2014 11:05:01 +1000

Section 9.2.2 puts some requirements on TLS ciphers and I'm just wondering
how the fallback is meant to work.

I'm testing a recent build of FF with latest jetty server.

The connection is negotiated as  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which
would be acceptable if the protocol was https, but because it is h2,  FF
fails the connection due to lack of AEAD.     This results in a connection
failure on the client, when it would have worked fine if http/1.1 was
accepted as the protocol instead.

So I'm just trying to get my head around how the fallback is meant to
happen?

Is it that in the ALPN accept of the connection, the server needs to
evaluate the offered protocols against the available ciphers and ignore the
protocols that don't have acceptable ciphers?     So in this case, our ALPN
code should have known that accepting h2-14 was not going to succeed
because the cipher was not acceptable (or there is not acceptable cipher...
I can't recall if the cipher is determined at that stage or not)?
Alternately, are we meant to modify the TLS cipher negotiation to notice if
ALPN h2 is being offered and thus not select an unacceptable cipher?

If the server does select an unacceptable cipher,  should the client just
fail? or should it retry either without h2 offered  or without unacceptable
ciphers?   I think it is unacceptable that FF and Jetty were unable to
communicate in this situation even though they had acceptable ciphers and
protocols in common.   One or the other or both needs better fallback and I
don't think section 9.2.2 gives enough guidance as to how that should be
done.

Also I'm a little bit concerned that many implementations might not have
sufficient control over their TLS layers to fully implement some
combinations.

Finally, it would be really good to know why http2 puts restrictions on TLS
above and beyond https?   Can that be described somewhere and has that been
checked so that it is future proof?

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: Greg Wilkins <[email-masked]>
Date: Fri, 5 Sep 2014 12:12:51 +1000

I've dug into this particular problem some more.

For the ALPN extension that we have done for OpenJDK 7, at the time we are
called back to select the protocol to use, the SslSession reports a cipher
of SSL_NULL_WITH_NULL_NULL.     Thus I don't have the information available
to exclude h2-14 from the protocol list on the basis of negotiated
cipher.   I then tried setting the acceptable cipher suites on the session
at that same point in the code, but unfortunately the OpenJDK library had
already picked the cipher (and just not told the session about it), so the
excluded cipher was used anyway.

So before we go hacking into the JDK code to see what we can change, it
would be good to know if we are meant to make the selected protocol a
function of the selected cipher, or if the selected cipher should be a
function of the selected protocol?

Reading RFC7301,  it makes no association between ciphers selection and
protocol selection.  But it does say :

   The ALPN extension does not impact the security of TLS session
   establishment or application data exchange.

Which kind of suggests that we should be selecting protocols as a function
of the cipher.  However I note that in a full handshake it looks like the
client selects the cipher, so it is unknown to the server until the next
round trip.   So maybe the server will have to advertise different lists of
available ciphers depending on the protocol selected.

So at the very least, we have a short term interoperability while we hack
our ALPN implementations to support some association between protocol and
cipher selection.     But somebody with more TLS smarts than me will have
to confirm if this is possible under RFC7301 or if we need to enhance ALPN
to support this kind of logic in a well defined manner.

Which brings me back to the question of why are we doing this again?   I
fully understand that there are unacceptable ciphers out there and we
should recommend that servers be updated and maintained with all the latest
knowledge to offer a secure set of ciphers.  But why is this set of
acceptable ciphers a function of protocol used (or vice versa)?     If a
cipher is unacceptable to carry HTTP/2 traffic, then why will falling back
to HTTP/1 be acceptable?   Can't we just recommend against poor ciphers but
still function if they are the only ciphers on offer?

regards

On 5 September 2014 11:05, Greg Wilkins <[email-masked]> wrote:

> Finally, it would be really good to know why http2 puts restrictions on
> TLS above and beyond https?   Can that be described somewhere and has that
> been checked so that it is future proof?
>
> cheers
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 4 Sep 2014 22:45:04 -0700

> to support this kind of logic in a well defined manner.

In TLS, server selects both the ALPN protocol and the cipher suite. I'm not
sure
what lead you to believe that the client selected the cipher suite, but
that's not
correct and if you can point me to the section in the TLS spec that made you
think that, I'll try to fix it.

This is a distinct question from what RFC 7301 says, just a technical
statement
about what servers can and can't do. With that said, I read the statement
you
quote above (from the security considerations section) as saying that this
doesn't make the handshake less secure. I don't think it's inconsistent
with 7301
to condition cipher suites on the ALPN negotatiation.

-Ekr

>> Section 9.2.2 puts some requirements on TLS ciphers and I'm just
>> wondering how the fallback is meant to work.
>>
>> The connection is negotiated as  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
>> which would be acceptable if the protocol was https, but because it is h2,
>> FF fails the connection due to lack of AEAD.     This results in a
>> connection failure on the client, when it would have worked fine if
>> http/1.1 was accepted as the protocol instead.
>>

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 5 Sep 2014 16:46:35 +1000

On 5 September 2014 15:45, Eric Rescorla <[email-masked]> wrote:

> In TLS, server selects both the ALPN protocol and the cipher suite. I'm
> not sure

I was confused by the state diagrams in 7301 and 5246  that show either the
server
or the client can first change the cipher suite.  But then I did not read
the 5246 in
detail, so probably not a fair reflection on those documents.

> to condition cipher suites on the ALPN negotatiation.

Ok.   But I still think that 7301 does not give any guidance on how this
can be done.

The jetty team implemented ALPN directly from 7301 and nowhere in does it
suggest that the extensions protocol selection may influence the cipher
suites
available or that the selected cipher suite may influence the selection of
the protocol.

The result is that we have developed a 7301 compliant extension that
is incapable of implementing the protocol/cipher selection logic implied by
h2-14 9.2.2.

My preference is to not to make a relationship between the two concepts and
that
acceptable ciphers should be configured by server not by protocol.    But
failing that,
I definitely need guidance as to how to proceed. Select protocol then
cipher?
Select cipher then protocol?  Select both at same time?    I don't think it
is acceptable
to have the cipher/protocol selection to be an implementation detail.

cheers

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Sep 2014 00:24:58 -0700

On 4 September 2014 19:12, Greg Wilkins <[email-masked]> wrote:
> Thus I don't have the information available to exclude h2-14 from the
> protocol list on the basis of negotiated cipher.

The server selects both ALPN and cipher suite.

If ALPN is picked first of those two in the OpenJDK implementation,
that's fine, as long as the cipher suite selection is OK.

A client offering "h2" should be including valid choices, so the only
problem is tweaking the suite selection process somehow.  In NSS,
there's a list of supported and enabled suites from which the server
picks the first available.  Ensuring that valid choices appear before
invalid ones will make software like that produce the right outcome.

It looks like OpenJDK does the same based on the order of
preferLocalCipherSuites and getActiveCipherSuites():
  http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/security/ssl/ServerHandshaker.java#l980

If you have preferLocalCipherSuites off, you should be OK with Firefox
as long as the necessary suites are enabled, but I'd want to turn it
on to avoid problems.  There might need to be some other tweaks to
enable ECDHE, I know that Chromium had some issues when in the server
role for DTLS because it's not on by default in OpenSSL/BoringSSL.

INADEQUATE_SECURITY is there as a backstop, should this process fail.
I don't see any reason why it should be necessary if you are correctly
configured.

---

From: Simone Bordet <[email-masked]>
Date: Fri, 5 Sep 2014 12:15:20 +0200

Hi,

On Fri, Sep 5, 2014 at 9:24 AM, Martin Thomson <[email-masked]> wrote:
> problem is tweaking the suite selection process somehow.

Can you remind why this is necessary at all ?
Section 9.2.2 says what, but not why, and I think it would be useful
to have some text that explains.

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 5 Sep 2014 20:56:53 +1000

Note that RFC7301 says:

   This document describes a Transport Layer Security (TLS) extension
   for application-layer protocol negotiation within the TLS handshake

If 9.2.2. is to stand, then I believe that we need a new version of ALPN
specification
(or errata or similar) that says something like:

   This document describes a Transport Layer Security (TLS) extension
   for negotiation of application-layer protocol and TLS cipher suite
   combinations within the TLS handshake

Otherwise, when ALPN is natively supported in the JVM8, there is nothing
stopping
them implementing it as we did according to RFC7301 and producing an
extension that
only negotiates protocol and thus cannot support what 9.2.2 requires.

It would also still be good to get an answer of why we need 9.2.2 ?
If the ciphers are inadequate for h2, then why aren't they inadequate for
http/1, spdy and
other protocols the ALPN might list?

---

From: Patrick McManus <[email-masked]>
Date: Fri, 5 Sep 2014 08:05:03 -0400

> other protocols the ALPN might list?

they might well be inadequate for all those protocols, but we accept them
for the sake of backwards compatibility. (basically the same reason we
accept http:// urls at all).

h2 is an opportunity to update to current best practice. If you design a
pure h2 service you can be more confident in its security properties.

---

From: Simone Bordet <[email-masked]>
Date: Fri, 5 Sep 2014 15:53:35 +0200

Hi,

> pure h2 service you can be more confident in its security properties.

But is not this concern orthogonal to HTTP/2.0 ?

If tomorrow those ciphers are discovered flawed or better ones
invented, why should the HTTP/2.0 specification be modified at all ?

For the record, while it may be possible to do something in JDK 8
about preferred ciphers (did not try yet), it's not possible in JDK 7
because the relevant methods have been added only in JDK 8.

Is this opportunity the only reason 9.2.2 is present in the HTTP/2.0
specification ?

Thanks !

---

From: Patrick McManus <[email-masked]>
Date: Fri, 5 Sep 2014 11:03:02 -0400

> accepted as the protocol instead.

right. h2-14 requires aead and the server selected h2 via alpn without also
using aead - so that's a h2 level protocol error on the server's part and
that connection can't proceed. The expected thing would have been for the
server not to select h2.

The question of what to do next in the client is tricky and fun to talk
about, but I think the standard does the right thing by steering clear of
it. As you note, firefox right now declares game over - hard fail. No doubt
the error page for it is in dire need of improvement :)

One part of that decision is the nature of the specific failure - auto
fallback to a less secure suite from a server that indicated it was capable
of a stronger suite (by signaling h2) has the hallmarks of a downgrade
attack. scary stuff.

The other part of that is just design experience that favors being
intolerant of errors - especially at early stages. These workarounds tend
to get added over time for bugwards compatibility,, but at this stage we
shouldn't feel that kind of pressure - its much more important to build an
ecosystem where things operate correctly when its full of those kinds of
written and unwritten rules. A lot of folks believe we're in an era where
"be liberal in what you receive" is no longer in the best interest of the
Internet.

I do agree this is tricky to get right (but worthwhile!). We had a bug
where we would occasionally send a TLS 1.0 client hello (due to some tls
intolerance logic) with h2 in the offer list. If h2 was selected, we
generated an error. We shouldn't do that - they aren't compatible.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 5 Sep 2014 11:15:43 -0400

> invented, why should the HTTP/2.0 specification be modified at all ?

The intent of the existing text is to provide minimum requirements for use
of a new protocol. If new approaches become a best practice in the future
they can be used with h2 (without modifying the h2 definition) as I
understand it. I'm sure Martin would entertain changes to the text to help
make that clear. And sure, as time goes by we will have problems along the
lines of "X is now known insecure, do I need to keep accepting it for
backwards compatibility" - but we don't have to start by allowing
X=RC4-SHA1 on day one.. this will help clear the decks of accumulated
cruft, which is worthwhile even if more cruft will inevitably arrive.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 05 Sep 2014 11:26:59 -0400

FWIW, there are lots of (non-TLS) RFCs that have been published with explicit TLS requirements over the years, but I am not aware of a single RFC or WG that hasn't regretted doing so because such requirements are made by non-experts and are quickly made obsolete by changes in TLS or new security vulnerabilities.

Publishing hard TLS/1.2 requirements (beyond a reference to RFC 5246) in HTTP2 would be, IMHO, a big mistake, particularly when the TLS WG is chartered to "deliver" 1.3 in November.  Plus, by allowing any conforming TLS/1.2 (or higher) implementation to be used for HTTP/2, you reduce the number of implementation issues (such as being discussed here) and allow future changes to TLS without needing to update HTTP/2 just to keep up.

On Sep 5, 2014, at 11:03 AM, Patrick McManus <[email-masked]> wrote:

> The connection is negotiated as  TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, which would be acceptable if the protocol was https, but because it is h2,  FF fails the connection due to lack of AEAD.     This results in a connection failure on the client, when it would have worked fine if http/1.1 was accepted as the protocol instead.
> 
> right. h2-14 requires aead and the server selected h2 via alpn without also using aead - so that's a h2 level protocol error on the server's part and that connection can't proceed. The expected thing would have been for the server not to select h2.
> 
> The question of what to do next in the client is tricky and fun to talk about, but I think the standard does the right thing by steering clear of it. As you note, firefox right now declares game over - hard fail. No doubt the error page for it is in dire need of improvement :)
> 
> One part of that decision is the nature of the specific failure - auto fallback to a less secure suite from a server that indicated it was capable of a stronger suite (by signaling h2) has the hallmarks of a downgrade attack. scary stuff.
> 
> The other part of that is just design experience that favors being intolerant of errors - especially at early stages. These workarounds tend to get added over time for bugwards compatibility,, but at this stage we shouldn't feel that kind of pressure - its much more important to build an ecosystem where things operate correctly when its full of those kinds of written and unwritten rules. A lot of folks believe we're in an era where "be liberal in what you receive" is no longer in the best interest of the Internet.
> 
> I do agree this is tricky to get right (but worthwhile!). We had a bug where we would occasionally send a TLS 1.0 client hello (due to some tls intolerance logic) with h2 in the offer list. If h2 was selected, we generated an error. We shouldn't do that - they aren't compatible.
>  

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Michael Sweet <[email-masked]>
Date: Fri, 05 Sep 2014 11:29:46 -0400

Patrick,

On Sep 5, 2014, at 11:15 AM, Patrick McManus <[email-masked]> wrote:
> 
> On Fri, Sep 5, 2014 at 9:53 AM, Simone Bordet <[email-masked]> wrote:
> 
>  
> The intent of the existing text is to provide minimum requirements for use of a new protocol. If new approaches become a best practice in the future they can be used with h2 (without modifying the h2 definition) as I understand it. I'm sure Martin would entertain changes to the text to help make that clear. And sure, as time goes by we will have problems along the lines of "X is now known insecure, do I need to keep accepting it for backwards compatibility" - but we don't have to start by allowing X=RC4-SHA1 on day one.. this will help clear the decks of accumulated cruft, which is worthwhile even if more cruft will inevitably arrive.

The TLS WG already has a draft outlawing RC4 for TLS/1.2.  And the UTA WG has a draft documenting the best practices for deployment.  There is no need for HTTP/2 to say anything about allowed or required cipher suites.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Sep 2014 09:44:48 -0700

On 5 September 2014 08:29, Michael Sweet <[email-masked]> wrote:
> The TLS WG already has a draft outlawing RC4 for TLS/1.2.

And it hasn't really changed the fact that RC4 is widely used (and
preferred).  Even with Microsoft penalizing RC4 users now, I don't see
it disappearing particularly fast.

The fact is, most of what we are recommending is OLD.  TLS 1.2 itself
is pretty old now at 6 years.  And it's all widely deployed.  What
we're forbidding is really old, and lots of it has problems that might
not mean that you are broken today (though RC4 is close).  And then
there are structural issues like the absence of PFS and problems with
the formulation (mac then encrypt).

What experience has shown is that it is really hard to remove crypto.
Even bad crypto.  We don't get many opportunities to get a clean break
and HTTP/2 was identified as that break point.

You might like to think that we're stepping outside of our scope of
authority, but it's always been the case that TLS is provided as a
tool.  Application protocols (and applications) are definitely
empowered to profile the protocol.  They pretty much all do to some
extent.

If you want to argue on process technicality grounds against us doing
this, that's not going to work.  A big part of why UTA exists is
because it is an applications area responsibility to determine how TLS
is best used.  We're going to rely on that work, but we're grown-ups
too and we have made some decisions for ourselves.  That's exactly how
this works.

---

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

Martin,

I'm arguing based on personal experience with IPP (which unfortunately also sought to make a "clean break" WRT cipher suites and TLS) where the mandatory cipher suite chosen (TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA) is no longer required and (based on what I see on the TLS list) is probably getting cut for TLS/1.3.  That choice also made it hard to push for TLS/1.2 support in printers (though we've been successful there) since the TLS/1.0 and cipher suite still needs to be dragged along...

This isn't a process issue, this is a "don't write a spec you'll have to update only because something in TLS has changed" issue. Instead of requiring specific cipher suites or outlawing others, require conformance to the current TLS specification and best practices, including the use (or exclusion) of cipher suites as defined by the TLS or UTA WGs.  Or if you really feel like you need to make a stand, put it in a companion document (that can be updated separately as needed) on HTTP/2 security that the main spec references.

---

From: Simone Bordet <[email-masked]>
Date: Fri, 5 Sep 2014 19:29:59 +0200

Martin,

> This isn't a process issue, this is a "don't write a spec you'll have to update only because something in TLS has changed" issue. Instead of requiring specific cipher suites or outlawing others, re…

FWIW, I agree with what Michael says above.

We have presented interoperability issues and Michael speaks from real
world experience, so there is something tangible to take into account,
and what is being suggested above seems a reasonable compromise.

I could not find any discussion in the mailing lists about what
ciphers to include or exclude, so can you please provide context about
when there was a consensus to choose these particular ciphers ?

Thanks !

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Sep 2014 10:38:14 -0700

> when there was a consensus to choose these particular ciphers ?

There was a discussion in Zurich, where we had a large contingent of
TLS folks.  That was where the original decision was made.  You can
find issues that track the decisions on github.  There was also a
discussion around cipher suite choice at the last two meetings.  All
of that should be minuted (and in recordings).

There are a few different things we're talking about here, but if you
want to talk about ciphers, then #498 is probably most appropriate.
#318 is the meta issue.  You can see #357 relates, as well as many of
the other ones here:
https://github.com/http2/http2-spec/issues?q=is%3Aissue+is%3Aclosed+TLS

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Sep 2014 11:13:07 -0700

On Thu, Sep 4, 2014 at 11:46 PM, Greg Wilkins <[email-masked]> wrote:

> I was confused by the state diagrams in 7301 and 5246  that show either
> the server

Ah, this is a naming problem. That message just means "go to the new cipher
suite". The cipher suites are negotiated in the handshake. Unfortunately, I
don't think we will change the message name (though we may eliminate
it in TLS 1.3)

> is incapable of implementing the protocol/cipher selection logic implied
> by h2-14 9.2.2.
>
> My preference is to not to make a relationship between the two concepts
> and that
> Select cipher then protocol?  Select both at same time?    I don't think
> it is acceptable

Interesting point. Generally, the h2 ciphers were chosen so that they are
the
ones we wish you would prefer anyway, so if you were to do so, then this
would work.

-Ekr

---

From: Michael Sweet <[email-masked]>
Date: Fri, 05 Sep 2014 16:35:35 -0400

[If these suggestions are acceptable, please let me know how you'd like these chopped up and I'll file issues accordingly...]

Martin,

After reviewing the issues I am still uncomfortable with having a list of proposed TLS 1.3 standard cipher suites and feature restrictions made required in the HTTP/2 specification.  These choices haven't even gone through TLS WGLC, and judging from the amount of discussion on the TLS list I would not want to make any decisions based on what may or may not be in TLS 1.3.

I am OK with the wording in section 9.2.

For section 9.2.1, the requirement for SNI makes sense, although it seems strange to put the core requirement on the TLS implementation; maybe:

   HTTP/2 implementations that support TLS MUST also support the Server Name
   Indication (SNI) [TLS-EXT] extension to TLS.  HTTP/2 clients MUST indicate
   the target domain name when negotiating TLS.

   (you might change "indicate" to "specify" here, but that's purely editorial)

The prohibition for compression probably only belongs in the Security Considerations.  I notice that compression is already a SHOULD NOT in the current version of TLS-BCP, and I think it is OK to make it a MUST NOT and cite the BREACH attacks.  Maybe provide a forward reference to section 10.6 at the beginning of 9.2.1 for all of the security-related feature prohibitions?

The prohibition for renegotiation needs to be considered carefully - this is an area of intense discussion in the TLS WG and I expect there will be some form of renegotiation/rekeying in TLS 1.3 to address long-lived connections (at least).  You *could* prohibit renegotiation to obtain client credentials, but even then I would make it a SHOULD NOT and cite interoperability and potential security concerns, and any SHOULD NOT/MUST NOT for security reasons belongs in section 10 (security considerations)...

I am VERY uncomfortable with Section 9.2.2 as currently written.  Basically it makes it impossible to use a TLS/1.2 [RFC5246] implementation since you are prohibiting the only required TLS/1.2 cipher suite (TLS_RSA_WITH_AES_128_CBC_SHA).  I would be much more comfortable requiring base TLS/1.2 (TLS_RSA_WITH_AES_128_CBC_SHA) and recommending the rest.

Finally, there is nothing in section 10 about the TLS-BCP recommendations; in addition to the two prohibitions from section 9.2.1, you could throw in the "MUST NOT negotiate RC4" and highlight other important stuff concerning TLS and HTTPS.

Last (editorial) issue: there are lots of TLS-foo references that really should be RFCnnnn references...

> On Sep 5, 2014, at 1:38 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Sep 2014 14:44:57 -0700

Let me try to break it up in response.

> After reviewing the issues I am still uncomfortable with having a list of proposed TLS 1.3 standard cipher suites and feature restrictions made required in the HTTP/2 specification.  These choices…

I can't really do anything about that without overturning a standing
decision.  I'm not the chair, but I'm guessing that you'd have to
exhibit more than discomfort for that to happen.

For some of what you are requesting here, some of that also requires
revisiting old decisions. You can find a lot of the records of
discussion and conclusions in the mailing list archives, or the closed
github issues if you need to reacquaint yourself with the particulars.

>    (you might change "indicate" to "specify" here, but that's purely editorial)

So you want to make this conditional?  Is that all?  Since this is a
section dedicated to TLS usage, I don't much see the benefit there.
The first sentence in 9.2 establishes conditionality.

> The prohibition for compression probably only belongs in the Security Considerations.  I notice that compression is already a SHOULD NOT in the current version of TLS-BCP, and I think it is OK to m…

I don't believe in concentrating all the security considerations in
the security consideration section, but a pointer makes sense (I see
we have none).

> The prohibition for renegotiation needs to be considered carefully

It was.  We've spent a lot of cycles on this issue since Brian first
raised the concern before the Zurich meeting.

We're not getting renegotiation in TLS 1.3, unless someone finds a
reason to overturn the consensus in the TLS WG (yes, it's not
unanimity).  There *might* be rekeying, and there *might* be some form
of spontaneous client authentication (the former seems more likely),
but there won't be the same generic renegotiation that TLS 1.2
provides.

> I am VERY uncomfortable with Section 9.2.2 as currently written.  Basically it makes it impossible to use a TLS/1.2 [RFC5246] implementation since you are prohibiting the only required TLS/1.2 ciph…

The suite we require is not especially new, and all the
implementations I'm aware of support it.  Impossible is definitely too
strong a word.

> Finally, there is nothing in section 10 about the TLS-BCP recommendations; in addition to the two prohibitions from section 9.2.1, you could throw in the "MUST NOT negotiate RC4" and highlight othe…

See above regarding the concentration of security considerations.  We
already suggest that the BCP is worth referencing, but we decided not
to wait for its completion.

> Last (editorial) issue: there are lots of TLS-foo references that really should be RFCnnnn references...

Those are just the symbolic reference labels.  Labels that were
purposefully selected.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 6 Sep 2014 07:58:16 +1000

On 6 September 2014 01:03, Patrick McManus <[email-masked]> wrote:

> right. h2-14 requires aead and the server selected h2 via alpn without
> also using aead - so that's a h2 level protocol error on the server's part
> and that connection can't proceed.
>

Agreed.  The FF client is following 9.2.2 correctly here.
The problem I have is that OpenJDK is following RFC5246 correctly and
Jetty's ALPN is following RFC7301 correctly - yet we ended up with no
communication.

I don't think it is acceptable for specifications to aggregate
unsuccessfully like that.   Sure I can try to influence the development of
ALPN in the JVM to support selection of cipher and protocol rather than
just protocol - but that is not captured by an RFC.

The expected thing would have been for the server not to select h2.

So 9.2.2 is not discouraging the use of old ciphers.   It is discouraging
the use of h2!

> the error page for it is in dire need of improvement :)
There is no error screen.  It leaves the page exactly as it was with the
previous contents.  Most confusing, but I'll hold you to account for that
once Jetty's own h2 failures are elegant and well logged.

I'm not sure we should go for any retries because the information is there
in the original handshake to establish communication, either h1 or h2,
using less desirable cipher.

> I'm happy to be intolerant of insecure ciphers.  If they are no good,
let's just make them unacceptable.  Let's not discourage the use of h2.

If we are not being liberal, then why are we letting client and server talk
over a poor cipher just because they are using a 20 year old protocol that
had  less consideration in its design to things like header injection etc.

> generated an error. We shouldn't do that - they aren't compatible.

Indeed.   But it is hard enough to explain cipher issues to users anyway,
so involving the protocol is going to make it harder for them to understand
and upgrade to new ciphers.      I would think we just need the end points
to exclude bad ciphers, warn for poor ciphers and prefer good ciphers
regardless of protocol.      Adding protocol to the mix is just mixing
orthogonal concerns

cheers

---

From: Andrei Popov <[email-masked]>
Date: Fri, 5 Sep 2014 22:14:45 +0000

To sum up: HTTP/2 spec imposes restrictions on TLS cipher suites.

Pros: 
1. "h2 is an opportunity to update to current best practice. If you design a pure h2 service you can be more confident in its security properties."
2. Is there anything else?

Cons:
a) TLS code now needs to filter ALPN IDs based on the negotiated cipher  suite, or the HTTP stack needs to filter cipher suites based on the enabled HTTP versions.
b) The server's security policy (e.g. allowed TLS protocol versions and cipher suites) is now coupled to the supported HTTP versions. System admin cannot change these (seemingly orthogonal) things independently.
c) More code complexity, deployment complexity, possible interop issues, failing connections...

So far the cons look more convincing to me than the pros, but maybe I am missing some important pros?

Cheers,

Andrei

-----Original Message-----
From: Michael Sweet [mailto:[email-masked]] 
Sent: Friday, September 5, 2014 1:36 PM
To: Martin Thomson
Cc: Simone Bordet; Patrick McManus; Greg Wilkins; HTTP Working Group
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

Martin,

>> ciphers to include or exclude, so can you please provide context 
>> about when there was a consensus to choose these particular ciphers ?
>

---

From: Brian Smith <[email-masked]>
Date: Fri, 5 Sep 2014 15:29:56 -0700

> After reviewing the issues I am still uncomfortable with having a list of proposed TLS 1.3 standard cipher suites and feature restrictions made required in the HTTP/2 specification.  These choices…

Michael,

I agree with you about one thing: It is a mistake to mention that
specific cipher suites must be implemented, because, like you noted in
your previous message, such requirements tend to be made obsolete
faster than the rest of the protocol is. I had previously argued that
here: http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/1268.html

> The prohibition for compression probably only belongs in the Security Considerations.  I notice that compression is already a SHOULD NOT in the current version of TLS-BCP, and I think it is OK to make it a MUST NOT and cite the BREACH attacks.

I think it is better to put all the TLS requirements in one place. I
think it is good to mention *why* TLS compression is prohibited in the
security considerations, but the statement that it is prohibited is
best left where it is, to reduce the chances of it being overlooked.
Note that BREACH is one issue, but the overall problem that is being
avoided is more general than BREACH.

> The prohibition for renegotiation needs to be considered carefully - this is an area of intense discussion in the TLS WG and I expect there will be some form of renegotiation/rekeying in TLS 1.3 to…

Renegotiation doesn't compose properly with HTTP/2 connection
coalescing, and that's why it is prohibited in HTTP/2. I think the
decision made was a reasonable trade-off and I don't think it is good
to revisit it now. It does mean that if your server requires
renegotiation and you can't get rid of that requirement, then HTTP/2
cannot be used by your server. But, I think everybody (Martin in
particular) is trying to get that resolved in a timely fashion so that
there are solutions available not long after the initial HTTP/2 spec
is finished.

> I am VERY uncomfortable with Section 9.2.2 as currently written.  Basically it makes it impossible to use a TLS/1.2 [RFC5246] implementation since you are prohibiting the only required TLS/1.2 ciph…

It was a mistake for the TLS 1.2 specification to say
TLS_RSA_WITH_AES_128_CBC_SHA is mandatory-to-implement at all, for the
reason that you and I both gave. But, that is in the past. And, note
that the TLS 1.2 specification allows an application profile of TLS to
override that requirement.

Although I disagree with mandating any particular cipher suite, the
more general HTTP/2 requirement that a forward-secret cipher suite be
used is appropriate.

> Finally, there is nothing in section 10 about the TLS-BCP recommendations; in addition to the two prohibitions from section 9.2.1, you could throw in the "MUST NOT negotiate RC4" and highlight othe…

It is likely HTTP/2 will get finished before TLS-BCP is finished.
Let's not create process problems by trying to cite the TLS-BCP
document. Also, IIUC, the TLS-BCP RFC can update the HTTP/2 RFC to
improve it after HTTP/2 is published, if there ends up being some
unforeseen conflict.

Cheers,
Brian

---

From: Michael Sweet <[email-masked]>
Date: Fri, 05 Sep 2014 18:35:22 -0400

Martin,

Responses inline...

On Sep 5, 2014, at 5:44 PM, Martin Thomson <[email-masked]> wrote:
> ...

RFC 5246 requires a conforming implementation to be able to negotiate TLS_RSA_WITH_AES_128_CBC_SHA.  HTTP/2 requires conformance to RFC 5246 but forbids negotiation of TLS_RSA_WITH_AES_128_CBC_SHA.  Do you not see the problem this creates?

> ...

You might get some different opinions on this when we are past WGLC.  Generally speaking, security considerations go in the section with that name, with pointers from other places as needed.  RFC 2223 and 3552 seem pretty clear on that point...

> ...

See my first comment above.  Section 9 requires conformance to RFC 5246.  Section 9.2.2 makes that conformance requirement impossible.

> ...

RFC references are supposed to be RFCnnnn.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 05 Sep 2014 19:02:16 -0400

Brian,

> avoided is more general than BREACH.

My concern is that none of the security considerations for those TLS requirements are currently documented in the security considerations section of the document.  And FWIW section 9.2 could have all of the requirements with references to section 10.x that talks about the TLS security considerations driving those requirements.

Put another way, if you don't know why something is required or forbidden, your implementation could be technically conforming while doing so insecurely because you  support a different TLS extension that has the same problems as renegotiation or compression or the "bad" cipher suites you are trying to avoid...

(and no, you can't protect against everything, but you *can* document your reasoning for the "important" stuff to guide implementors and future editors...)

> coalescing, and that's why it is prohibited in HTTP/2.

I understand why we don't want renegotiation-for-getting-client-credentials with HTTP/2. But the other use of renegotiation (re-keying) is still valid in this case and probably more relevant since a coalescing proxy will need re-keying more often than a direct connection...

In any case, the current text doesn't say why renegotiation is not allowed in the general case or why it is OK to allow initially (which would seem to have the same problems with coalesced connections and creates more interop problems when proxies are involved...)

> override that requirement.

I must have missed that - everything I see in there says it is unconditionally required in order for TLS/1.2 implementations to interoperate.

And even if an application profile *can* override the requirement, I wouldn't want to create a profile that does not guarantee that any two conforming implementations can work with each other.  And that would mean naming one or more required cipher suites, and IMHO *if* that is the path chosen then it should happen in a separate document defining just the TLS/1.2 profile so that it can be updated independent of HTTP/2 (and used by other protocols if it turns out to be generally useful...)

> improve it after HTTP/2 is published, if there ends up being some

I thought informative references to I-Ds were allowed?

---

From: Brian Smith <[email-masked]>
Date: Fri, 5 Sep 2014 16:16:01 -0700

On Fri, Sep 5, 2014 at 4:02 PM, Michael Sweet <[email-masked]> wrote:
> Brian Smith wrote:

http://tools.ietf.org/html/rfc5246#section-9 says:

   In the absence of an application profile standard specifying
   otherwise, a TLS-compliant application MUST implement the cipher
   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5 for the
   definition).

The HTTP/2 draft is defining an "application profile standard
specifying otherwise," so an application profile standard isn't
absent, so there is no requirement that TLS_RSA_WITH_AES_128_CBC_SHA
be implemented for HTTP/2. In other words, the TLS specification was
written specifically to allow the type of thing that the HTTP/2 draft
is doing.

Also, logically, we seem to agree that it is a bad idea to specify
specific cipher suites as mandatory-to-implement, so I don't think we
should worry too much about requirements in specifications that have
made that mistake. Instead, let's just not make that mistake any more.

Cheers,
Brian

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Sep 2014 16:35:57 -0700

On 5 September 2014 14:58, Greg Wilkins <[email-masked]> wrote:
> ALPN in the JVM to support selection of cipher and protocol rather than just
> protocol - but that is not captured by an RFC.

You shouldn't have to.  Have you tried my suggestions at all?

> I'm happy to be intolerant of insecure ciphers.  If they are no good, let's
> just make them unacceptable.  Let's not discourage the use of h2.

As the draft explains, clients will still need to offer those insecure
ciphers for HTTP/1.1 backwards compatibility.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 5 Sep 2014 16:34:27 -0700

On Fri, Sep 5, 2014 at 3:35 PM, Michael Sweet <[email-masked]> wrote:

> RFC 5246 requires a conforming implementation to be able to negotiate
> TLS_RSA_WITH_AES_128_CBC_SHA.  HTTP/2 requires conformance to RFC 5246 but
> forbids negotiation of TLS_RSA_WITH_AES_128_CBC_SHA.  Do you not see the
> problem this creates?
>

This is actually not a conformance problem, since RFC 5246 has an explicit
escape hatch for applications (https://tools.ietf.org/html/rfc5246#section-9
)

   In the absence of an application profile standard specifying
   otherwise, a TLS-compliant application MUST implement the cipher
   suite TLS_RSA_WITH_AES_128_CBC_SHA (see Appendix A.5
<https://tools.ietf.org/html/rfc5246#appendix-A.5> for the
   definition).

Note: I'm not saying that requiring AEAD is wise or unwise, but merely

that it's not a process problem for HTTP to do so.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Sep 2014 16:37:27 -0700

> RFC 5246 requires a conforming implementation to be able to negotiate TLS_RSA_WITH_AES_128_CBC_SHA.  HTTP/2 requires conformance to RFC 5246 but forbids negotiation of TLS_RSA_WITH_AES_128_CBC_SHA.…

Yes.  And it would be a problem if we hadn't already fixed it.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 6 Sep 2014 14:34:58 +1000

> You shouldn't have to.  Have you tried my suggestions at all?

I've not tried your suggestion because it is not available on JDK7.

Besides, my concern is not about how to make my implementation work, I'm
aware of
several fiddles I can do to make a good cipher be selected.

My concern is that implementations which comply with the relevant RFCs can
be put
together and not work.  There should be no need of fiddling functionality
outside of the
scope of the RFCs to make them work.

9.2.2 wants the server to select an acceptable protocol/cipher
combination,  but there
is nothing in RFC7301 that requires cipher/protocol selection functionality
to be offered by a ALPN extension. ALPN is not an extension for cipher
negotiation.

So 9.2.2 may not be implemented for those that are not implementing the
entire stack
themselves.You can't just say it is fixed because some can hack outside of
the scope
of the RFCs to pick an acceptable cipher/protocol combination.  Compliant
ALPN
implementations may not offer that functionality.

If you want a TLS extension that can negotiate cipher AND protocol, then
than needs
to be described in an RFC.     We can write something today that works, but
it will be
operating outside of the standards.

> ciphers for HTTP/1.1 backwards compatibility.

Client and server already negotiate the most preferable common cipher.  How
does
adding protocol to that already accepted selection mechanism influence the
deprecation of poor ciphers in any way?

If you want to stop old servers using poor ciphers, then the clients should
stop
offering those ciphers.   Talking h1 instead of h2 does not make the
conversation
any more secure and doesn't influence the server in anyway at all because it
doesn't offer h2 anyway.

All we are doing is hindering the deployment of h2 in environments that may
have
limited scope to enhance/deprecate/update their ciphers or the cipher
selection
algorithm.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 5 Sep 2014 22:03:35 -0700

> scope of the RFCs to make them work.

The extent of the fiddling is either zero (this just works in NSS and
OpenSSL to my knowledge) or - in things like the JDK - setting a
preference order that favours valid suites over invalid ones.  It's
not hard.  If you have ALPN, then you probably already have what you
need to interoperate in just about every TLS implementation I've seen.
You just need to know how to influence suite selection.

> deprecation of poor ciphers in any way?

Preferable is subjective.  We've seen that demonstrated many times
where servers pick RC4 over better ciphers because ...well, I can only
speculate.

> offering those ciphers.

Do you want to break the web.  We are taking a hard line, but it tends
to be unpopular:
http://it-beta.slashdot.org/story/14/09/05/2120246/mozilla-1024-bit-cert-deprecation-leaves-107000-sites-untrusted

If clients don't send the "bad" ciphers, then large swathes of the web
stop working.  No browser wants to do that because that's a trigger
for a mass exodus of users.  So we end up stuck with ciphers that are
sort-of-bad-but-not-broken-enough-to-pull.  Which sucks.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 6 Sep 2014 16:36:34 +1000

> where servers pick RC4 over better ciphers because ...well, I can only

Exactly!  Sometimes infrastructure that is out of your control does things
according to the standards that you would rather they didn't.

I don't see how requiring h2 capable servers to sulk in protest and only
serve h1 is going to help?   Just because browser vendors are unwilling to
deprecate bad ciphers as it may affect their market share, you instead
want servers to try to force change by withholding h2 services!

It is a form of protest a-kin to holding your breath until you get your
way!
Nobody will notice the protest as the web will just work as it always has
serving h1 over old ciphers.  Victory for the status quo!

So we end up stuck with ciphers that are
> sort-of-bad-but-not-broken-enough-to-pull.  Which sucks.

Sure that sucks, but I'm not sure it is our problem to fix.
I want world peace too, but making that a requirement for using h2 is not
going to help.

<offtopic>

It's not hard. ... You just need to know how to influence suite

selection.... Do you want to break the web.

Geeeeeeeeeeeeeeeeeeeeze you like to troll sometimes!

I do know how to write code to pick something from a preference list....
I had realised that cipher selection has something to do with this
conversation.....   I spend all my free time in the WG in an effort to
destroy web connectivity as we know it !)

</offtopic>

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 17 Sep 2014 15:44:52 +1000

I have opened https://github.com/http2/http2-spec/issues/612 because this
issue has not been resolved enough for me to understand enough to implement
a working solution.

As well as my concern regarding the required capabilities of ALPN, I am
struggling to work out how to implement 9.2.2 and I think there are going
to be interoperability problems into the future. Specifically I think it
will become impossible for a client to ever exclude a cipher from h2
acceptability without risking communication failure.

The basic problem occurs if ever the client and server disagree on exactly
what is a h2 acceptable cipher.  The flow of the problem is:

   1. Client offers connection with a set CLIENT_OK_CIPHER which is the
   union of CLIENT_OK_TLS_CIPHERS and CLIENT_OK_H2_CIPHERS
   2. The server only sees the union set, so it does not know what ciphers
   the client think are h2 acceptable.  The server wants h2, so it picks a
   cipher from the intersection of CLIENT_OK_CIPHERS and SERVER_OK_H2_CIPHERS
   3. If SERVER_OK_H2_CIPHERS != CLIENT_OK_H2_CIPHERS then a cipher may be
   picked that server thinks is h2 OK, but the client rejects because of it's
   interpretation of 9.2.2 at that time in the future.
   4. The client and server fail to communicate even though they have
   ciphers and protocols in common!

The only way to avoid this problem is for the client and server to
absolutely agree on what ciphers are h2 OK for all time and never ever ever
EVER disagree.     This might be possible if 9.2.2 is rigorously written in
a future proof way, but it is not:

   HTTP MUST NOT be used with cipher suites that
   use stream or block ciphers.     Authenticated Encryption with
   Additional Data (AEAD) modes, such as the Galois Counter
   Model (GCM) mode for AES [RFC5288] are acceptable.

So currently AES_128_CBC is an unacceptable h2 block cipher, but AES_128_GCM
is accepted.   Do I hard code that AES_128_CBC is unacceptable or that
AES_128_GCM is acceptable? If GCM is acceptable now, will GCM2 be
acceptable in the future?  As written this clause does allow for future
block ciphers with AEAD modes, but I don't know what they are in advance,
so I can't hard code them?  Will there ever be acceptable block ciphers
that use something other that AEAD?

Don't hard code I hear you say??? use a black/white list?????   Sure that
allows both client and server to future proof their users interpretation of
9.2.2, but that is now just subjective configuration and there is
absolutely no way that that client and servers will maintain the same h2
acceptable black/white lists.  If a client ever excludes a cipher from it's
h2 acceptable set before a server has, then communication failure will
result, even though client and server share acceptable ciphers and
protocols!
In short, to avoid communication failure, the server either has to just use
http/1 or it has to be absolutely sure it knows precisely what ciphers are
h2 acceptable to the client.   I am unable to implement that kind of future
proof telepathy and making it a configurable set just gives somebody else
the impossible task of knowing what is client h2 acceptable.

regards

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 17 Sep 2014 18:59:56 +1200

On 17/09/2014 5:44 p.m., Greg Wilkins wrote:
> I have opened https://github.com/http2/http2-spec/issues/612
> because this issue has not been resolved enough for me to
> understand enough to implement a working solution.
> 
> As well as my concern regarding the required capabilities of ALPN,
> I am struggling to work out how to implement 9.2.2 and I think
> there are going to be interoperability problems into the future.
> Specifically I think it will become impossible for a client to ever
> exclude a cipher from h2 acceptability without risking
> communication failure.
> 
> The basic problem occurs if ever the client and server disagree on
> exactly what is a h2 acceptable cipher.  The flow of the problem
> is:
> 
> 1. Client offers connection with a set CLIENT_OK_CIPHER which is
> the union of CLIENT_OK_TLS_CIPHERS and CLIENT_OK_H2_CIPHERS

I think this is where your problem is occuring.

Sending the union of cipher suites only works if fallback is permitted
in-band. Such as fallback between TLS versions; when TLSv1.3 prohibits
a cipher and TLSv1.2 permits it the client can offer and uses
whichever TLS version the server chosen cipher permits.

To meet the 9.2.2 criteria for sending ALPN "h2" the client must send
the intersection of those two sets, not the union.

Senders can only have a chance of successful communication when their
sent cipher suite will work with every permutation of ALPN signals
offered. ie it must omit the ALPN "h2" indicator in order to send the
union which includes h2-incompatible ciphers.

Logically this selection principle carries over as a general
rule-of-thumb for any other ALPN token which limits ciphers or
encryption properties. Or even other TLS extensions that limit cipher
suite.

> 2. The server only sees the union set, so it does not know what
> ciphers the client think are h2 acceptable.  The server wants h2,
> so it picks a cipher from the intersection of CLIENT_OK_CIPHERS and
> SERVER_OK_H2_CIPHERS

Following the rule of thumb, all delivered choices are h2 compatible,
HTTP/1.1 compatible and compatible.

> 3. If SERVER_OK_H2_CIPHERS != CLIENT_OK_H2_CIPHERS then a cipher
> may be picked that server thinks is h2 OK, but the client rejects
> because of it's interpretation of 9.2.2 at that time in the
> future.

Following the rule of thumb, this cannot happen.

> ciphers and protocols in common!

Following the rule of thumb this can still happen, but only in the
form of client and server completely disagreeing on cipher suites.

h2 is nothing special in this regard. We see that happening anyway
when both ends are restrictied to incompatible SSL/TLS versions. Such
as old SSL-only clients trying to contact a locked down TLS/1.2-only
server.

IMO 9.2.2 is overly restrictive in naming ciphers and types. We should
just reference the TLS working groups BCP document "latest version"
and leave the campaign for better TLS use in the TLS WG. *They* are
the experts on TLS best-practice after all.

Amos

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 17 Sep 2014 17:13:03 +1000

> the intersection of those two sets, not the union.

That is not how 9.2.2 is written.  In fact is specifically calls out the
opposite:

   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.

So in this case FF is advertising that it will accept h2 unacceptable
ciphers.  I'm running my server on java-7 that looks like by default it has
no h2 acceptable ciphers (now that's a big hurdle to adoption), and I'm
trying to write the future proof code that will let my implementation
realise that none of my available ciphers are h2 acceptable and thus fall
back to http/1 (another speed bump in the road to adoption) and I find that
I can't work out an algorithm for that without hard coding specific
knowledge of today's cipher names or using a black/white list that is
guaranteed not to be updated in sync with the clients.

Ie I can make this work today, but I can give cannot write something that
will I know will work tomorrow!

cheers

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 17 Sep 2014 10:32:41 +0300

> that use something other that AEAD?

TLS currently divides ciphersuites into stream, block or AEAD.

This division comes from the way the ciphersuite is used in TLS. It doesn't
actually come from crypto primitives used (e.g. AES is considered to be block
cipher, but AES-GCM and AES-CCM ciphers in TLS are AEAD).

And because type determines how it is used, the TLS stack must know the type
of each ciphersuite it can negotiate. It can also be found on definitions
of ciphersuites (since those need to specify how to implement it).

However, in the future, there may be ciphersuite of some currently unknown
fourth type (i.e. not stream, block nor AEAD).

> result, even though client and server share acceptable ciphers and

If TLS stack has a way to query properties of ciphersuites, that could be
used. Unfortunately, I don't think all widely used ones do.

And if either end does not query the TLS stack but instead uses a whitelist
and then TLS stack gets updated (best practice is to dynamically link it,
so it can be updated on its own!)... Ouch.

The current ciphersuites are not the problem. It is the future ones. E.g.
if something like Google's nonstandard Chacha20-Poly1305 gets added (IRTF
CFRG has working document on cipher, after that is sent to RFC editor,
expect request for adoption on document on using that with TLS). Type: AEAD.

Also, that cipher would not have "_CCM(_|$)" or "_GCM(_|$)" in its name (like
all current AEAD ciphers do).

Or if you want really nasty one, add something using the Chacha20 cipher from
SSH (it is different from previous). Type: ??? (it sure isn't AEAD, block nor
stream in TLS)!

> the impossible task of knowing what is client h2 acceptable.

There are more subtle failures. Like client offering a set of H2-compatible
and H2-incompatible ciphersuites and ALPNs of h2 and h1. And then the TLS
stack doesn't know of coupling between h2 and ciphersuites, and proceeds
to pick some H2-incompatible ciphersuite and ALPN h2. Boom.

And the client and server can't get away by just including H2-compatible
ciphersuites. That would cause enormous amount of failures with H1 servers.

-Ilari

---

From: Brian Smith <[email-masked]>
Date: Wed, 17 Sep 2014 00:52:40 -0700

> expect request for adoption on document on using that with TLS). Type: AEAD.

When those new cipher suites get standardized, you (the product
developer) will become aware of them, probably WELL before your TLS
stack vendor actually implements them. As a responsible software
vendor, you've already made it easy for users of your software to
install updates of your software, so you can simply write a patch to
extend your pattern matching logic. Given that, you can maintain a
whitelist of cipher suites (or patterns of cipher suite names) that
you will negotiate HTTP/2 with, knowing that very rarely you will need
to issue an update that expands that whitelist. If a cipher suite is
not on your whitelist, you negotiate HTTP/1.

In parallel with that effort, you can work with your TLS stack vendor
to extend their API so that their API can answer questions about
supported cipher suites, such as "Is this cipher suite using ephemeral
key exchange" and "is this cipher suite an AEAD one?" After your TLS
stack vendor implements said API, over time fewer users of your
software will rely on your extremely rare patches to update the
HTTP/2-allowed cipher suite whitelist.

By the way, the browser has to do the same thing, in order to decide
which cipher suites to block for HTTP/2, and they manage just fine.

And, if you simply have your server enable the TLS_ECDHE_*_AES_*_GCM_*
cipher suites (using the NIST P-256 curve), and prefer them ahead of
all others, for both HTTP/1 and HTTP/2, you can entirely avoid doing
even the stuff I mentioned above.

Cheers,
Brian

---

From: Cory Benfield <[email-masked]>
Date: Wed, 17 Sep 2014 09:10:28 +0100

> even the stuff I mentioned above.

I think this is really the simplest approach. Prioritise ciphers that
are acceptable for use with h2 and have your server ignore the
client's priorities in favour of its own. If the client offers *any*
h2 ciphers you'll use them, otherwise you can assume that the client
can't do h2 (or at least can't according to the spec). In the HTTP/1.1
case all you've done is use strong ciphers for every connection that
supports them: I'm sure you'll get over it!

---

From: Roland Zink <[email-masked]>
Date: Wed, 17 Sep 2014 10:45:22 +0200

So how are new ciphers added later? Does this require a new HTTP2 RFC, 
or a new TLS RFC or do they need to be registered with IANA? What if one 
of the now acceptable ciphers is no longer considered secure and should 
be disabled?

Doesn't this cipher selection belong into TLS and not h2?

Regards,
Roland

On 17.09.2014 07:44, Greg Wilkins wrote:
> I have opened https://github.com/http2/http2-spec/issues/612 because 
> this issue has not been resolved enough for me to understand enough to 
> implement a working solution.
>
> As well as my concern regarding the required capabilities of ALPN, I 
> am struggling to work out how to implement 9.2.2 and I think there are 
> going to be interoperability problems into the future. Specifically I 
> think it will become impossible for a client to ever exclude a cipher 
> from h2 acceptability without risking communication failure.
>
> exactly what is a h2 acceptable cipher. The flow of the problem is:
>
>     so it picks a cipher from the intersection of CLIENT_OK_CIPHERS
>     and SERVER_OK_H2_CIPHERS
>  3. If SERVER_OK_H2_CIPHERS != CLIENT_OK_H2_CIPHERS then a cipher may
>     be picked that server thinks is h2 OK, but the client rejects
>     because of it's interpretation of 9.2.2 at that time in the future.
> absolutely agree on what ciphers are h2 OK for all time and never ever 
> ever EVER disagree.     This might be possible if 9.2.2 is rigorously 
> written in a future proof way, but it is not:
>
> So currently AES_128_CBC is an unacceptable h2 block cipher, but 
> AES_128_GCM is accepted. Do I hard code that AES_128_CBC is 
> unacceptable or that AES_128_GCM is acceptable?If GCM is acceptable 
> now, will GCM2 be acceptable in the future? As written this clause 
> does allow for future block ciphers with AEAD modes, but I don't know 
> what they are in advance, so I can't hard code them?  Will there ever 
> be acceptable block ciphers that use something other that AEAD?
>
> Don't hard code I hear you say??? use a black/white list?????   Sure 
> that allows both client and server to future proof their users 
> interpretation of 9.2.2, but that is now just subjective configuration 
> and there is absolutely no way that that client and servers will 
> maintain the same h2 acceptable black/white lists.  If a client ever 
> excludes a cipher from it's h2 acceptable set before a server has, 
> then communication failure will result, even though client and server 
> share acceptable ciphers and protocols!
>
> In short, to avoid communication failure, the server either has to 
> just use http/1 or it has to be absolutely sure it knows precisely 
> what ciphers are h2 acceptable to the client.   I am unable to 
> implement that kind of future proof telepathy and making it a 
> configurable set just gives somebody else the impossible task of 
> knowing what is client h2 acceptable.
>
> regards
>
>
>

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 17 Sep 2014 20:05:07 +1000

Brian,

the problem is not coming up with an algorithm to decide on what
ciphers are acceptable.  The problem is coming up with EXACTLY THE
SAME algorithm as all clients to decide what ciphers are acceptable.

If at some time in the future the client and server interpret 9.2.2
differently
against the then current available ciphers, then it is possible for the
server
to select, in good faith a cipher that it thinks is h2 acceptable, but the
client
does not.  The result is GO_AWAY and no retry.

Worse yet, a server has to deal with multiple user-agents out there, that
might
eventually have different interpretations of what an acceptable h2 cipher
is.
The server is then going to have to do user-agent guessing before it has
even
accepted a connection from the client!  Ugh!

So yes I mostly fix this today, with a regex or by hard coding some AEAD
requirements in the same way that FF has done.    But my question is,
how do I keep that regex and hard coded requirements up to date with all
the browsers out there?   What mechanism is there to ensure that we all
update
our regex's and code in lockstep?    If we can't update in lockstep, then
this problem is again going to cause communication failures.

So I can't simply write a patch, unless I know that all client vendors are
going
simultaneously write and release the same patch for their product and the
entire
universe turns it on at precisely the same time!

Actually, even today, if presented with some funky ciphers like Ilari has
highlighted,
how do I know that I've implemented 9.2.2 exactly the same as FF and that
they have
it exactly the same as Chrome, Opera, etc.?  9.2.2 is too vague and terms
like "such as" are not defined in RFC2119

---

From: Brian Smith <[email-masked]>
Date: Wed, 17 Sep 2014 12:02:52 -0700

On Wed, Sep 17, 2014 at 3:05 AM, Greg Wilkins <[email-masked]> wrote:
> differently the then current available ciphers, then it is possible for the
> server select, in good faith a cipher that it thinks is h2 acceptable, but the
> client does not.

I think you can expect that browsers will not enforce requirements
stricter than what draft 14 requires.

> might eventually have different interpretations of what an acceptable h2
> cipher is.

This would be a bug in the client. I don't think it is worthwhile to
worry about such buggy clients.

> But my question is, how do I keep that regex and hard coded requirements
> up to date with all browsers out there? What mechanism is there to ensure
> that we all update our regex's and code in lockstep?

"If the client offered the cipher suite in its ClientHello, and the
cipher suite fulfills the requirements imposed by the HTTP/2 spec,
then assume the client will accept it for HTTP/2. Otherwise, don't."

> 9.2.2 is too vague and terms like "such as" are not defined in RFC2119

draft 14 is clear enough for me to classify cipher suites into
"acceptable" and "not acceptable". By default, assume that a cipher
suite is not acceptable and you'll be fine.

Cheers,
Brian

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 18 Sep 2014 10:09:54 +1000

> suite is not acceptable and you'll be fine.

So tell me how 9.2.2 defines the handling for the following situation.

Consider clients and servers written in java, so they inherit their ciphers
from the JVM. At some stage in the future a GCM is replaced by XYZ and
added to the JVM, so it is part of the acceptable TLS ciphers, but the h2
clients and servers implementations have adopted your advice to "By
default, assume that a cipher suite is not acceptable".   So everybody is
assuming that XYZ is not h2 acceptable.

So firstly this could be a problem if XYZ was introduced because of a
security flaw in GCM, as if implementation removed support for GCM, then we
could see a mass fallback to http/1, because TLS would not negotiate a h2
acceptable cipher.

But let's say that when this happens, we are smart and we work out that XYZ
is acceptable for h2. So we are going to modify our implementations to also
consider XYZ as h2 acceptable.

When can the server deploy XYZ h2 acceptability?   If it does so before the
clients, then it will immediately lose connectivity with all clients.
If it waits until all the clients are updated, then it will be waiting
forever and the web will have reverted to http/1.1.   If it goes in
between, there will always be a large subset of clients where the failure
mode is failed connection rather than fallback to old protocol or old cipher

In short because of 9.2.2, there is no migration path to the new XYZ cipher
that does not involve losing connectivity with a large proportion of
clients.

This is not a theoretical problem.    It is a real problem that I have
experienced as FF rolled out their AEAD restriction as rqeuired by 9.2.2
before jetty had implemented the same restriction and while AEAD is not
available on java-7.  I could implement the AEAD restriction in jetty now
to get connectivity with FF, but would lose connectivity with h2 clients
running java-7.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Sep 2014 19:14:24 -0700

On 17 September 2014 17:09, Greg Wilkins <[email-masked]> wrote:
> from the JVM. At some stage in the future a GCM is replaced by XYZ and added
> to the JVM, so it is part of the acceptable TLS ciphers, but the h2 clients
> and servers implementations have adopted your advice to "By default, assume
> that a cipher suite is not acceptable".   So everybody is assuming that XYZ
> is not h2 acceptable.

You can't suddenly pull a cipher suite that people rely on.  We rely
on GCM.  We require that implementations support it.

Yes, there will be implementations that pick up XYZ, but also don't
know that it's OK.  That's expected behaviour sadly.  Not all
implementations will be able to examine the properties of the
available cipher suites and use properties to determine if they are OK
to use.

> This is not a theoretical problem.

I disagree, it's a hypothetical problem.

> It is a real problem that I have
> available on java-7.  I could implement the AEAD restriction in jetty now to
> get connectivity with FF, but would lose connectivity with h2 clients
> running java-7.

I'm not sure that this is quite right.  Unless the Java 7 code is
singificantly different to the Java 8 code, you should have been able
to influence suite selection so that a good suite (i.e., an acceptable
one) was chosen.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 18 Sep 2014 14:18:19 +1000

> on GCM.  We require that implementations support it.

Well leaving aside the aspect of requiring support for all time for a
security cipher....

My example is not saying that GCM has been revoked, only that a better
version called XYZ becomes available.

> available cipher suites and use properties to determine if they are OK

Exactly my point!!!!  If implementations pickup XYZ and some
know it is OK but some don't, then we have connection failure.

NOT fallback to GCM

NOT fallback to http1

It is GO_AWAY with no retry.  Game Over!

Server can't be smart and pick a workable protocol+cipher combination
because
it is impossible to know what all clients out there think is an acceptable
protocol+cipher combination.

Thus you are saying that it is sadly expected behaviour that we have built
in a
total protocol failure at some future date when there is a better cipher
suite
than GCM available.

> to influence suite selection so that a good suite (i.e., an acceptable

It is not about tricking the selection to make it work.  It is about
designing
a standard that wont fail given normal expected conditions.

Note also that we are in discussions with the OpenJDK developers about
their ALPN
implementation.  They are pushing back about allowing ALPN extension to
influence
the cipher selection.

Also note that the problem with java 7 is that it doesn't provide any GCM
ciphers at all:

http://docs.oracle.com/javase/7/docs/technotes/guides/security/SunProviders.html

http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html

So part of the problem that h2 cannot be deployed on java 7 (which I think
is a pretty
big deficiency, but not what I'm currently raising).

I understand that 9.2.2 requires us to support GCM, but the example of
moving from
java7 with CDC to java 8 GCM has shown a real interoperability problem as
we lost
connectivity with FF because it has implemented the GCM restriction before
we have.
We could implement the GCM restriction, but then nothing is stopping the
same
complete failure when XYZ eventually comes along.

I've got to this point because I have been trying to implement the GCM
restriction
in jetty, but am unable to provide and implementation to

   public static String[] getH2AcceptableCiphers(String[] availableCiphers)
{}

that is robust in the face of arbitrary available ciphers.   Unless we
implement
exactly the same algorithm as FF, Chrome, Opera and all other clients, then
we will have communication failure.   If I make it a configuration lookup,
then
we will certainly have failures.

To remove any doubt whatsoever, I can absolutely can not live with 9.2.2.

regards

---

From: Stuart Douglas <[email-masked]>
Date: Thu, 18 Sep 2014 14:53:16 +1000

I have been looking through the archives and I can't seem to find the 
discussion about how this requirement came about, and I am really 
struggling to understand why it is necessary.

I can't really see how it provides any increased security, given that if 
a cypher that meets these requirements is not available the client is 
expected to fallback to HTTP/1.1 and communicate over the supposedly 
less secure cypher anyway.

Stuart

Martin Thomson wrote:
> On 17 September 2014 17:09, Greg Wilkins<[email-masked]>  wrote:

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 18 Sep 2014 15:21:12 +1000

On 18 September 2014 14:53, Stuart Douglas <[email-masked]>
wrote:

> I can't really see how it provides any increased security, given that if a
> cypher that meets these requirements is not available the client is
> expected to fallback to HTTP/1.1 and communicate over the supposedly less
> secure cypher anyway

Stuart,

Martin hinted at the motivation earlier in this thread:

> sort-of-bad-but-not-broken-enough-to-pull.  Which sucks.

So he is saying that because browser vendor value market share more than
their users security it is apparently our job to withhold the h2 protocol
or just fail to connect in an  effort to push them towards being good web
citizens.

I don't actually agree with the premise that browser vendors are that
morally corrupt.  I think they have a difficult line to walk between
offering reasonable security and wide spread connectivity.       If they
are offering old ciphers then I am sure that there are significant origin
resources that can only be accessed with them.

But let's accept the premise that browser vendors are indeed morally
corrupt and will deploy insecure ciphers rather than lose market share.
Let's also assume that origin server deployers are also prepared to accept
those bad ciphers and make their content available over them...  I have
absolutely no idea how allowing those two to tango over http/1 rather than
h2 pushes them to any better security practises.   Perhaps the failing
abysmally to connect part might be a bit more persuasive, but I expect that
is more likely to make them remove the good ciphers.

If failure to connect is a driver to better cipher policy, then  we need
not hobble h2 to achieve that.  Instead the browser vendors and server
deployers can simply grow a pair and remove the bad ciphers.

regards

>>> added

---

From: Cory Benfield <[email-masked]>
Date: Thu, 18 Sep 2014 09:33:15 +0100

Greg, I've rearranged your post below because I found it flowed weirdly.

On 18 September 2014 06:21, Greg Wilkins <[email-masked]> wrote:
> offering reasonable security and wide spread connectivity.       If they are
> offering old ciphers then I am sure that there are significant origin

Alright, this makes sense. We agree on the original premise, but let
me state it outright: all user-agents are strongly incentivized to
make as many connections as they possibly can. Being unable to provide
a resource to a user almost always costs you that user. Users rarely
pick a browser (e.g. Chrome), try to connect to a resource and find
that it fails where another browser (say IE) succeeded, and then say
"Thankyou Chrome for protecting me from myself!" They say "Chrome
sucks and doesn't work". This is the exact same reason Microsoft have
long had a team whose sole purpose is to specially code bugs *back in*
to new Windows versions to prevent programs breaking.

Most users will never thank a user-agent for making them more secure,
but they will always blame a user-agent for refusing to fetch
information for them. If there is a competitor user-agent that makes
them less secure but gives them access to a resource they want,
they'll just switch to that. Given that most browsers are not
charities, it cannot be a surprise that they aim to increase their
market share. Everyone is very nice in this forum because civility is
good and the world is made better by us all getting a bite at the
apple, but don't for a moment think that we're not all in some form of
competition.

> their users security it is apparently our job to withhold the h2 protocol or
> just fail to connect in an  effort to push them towards being good web
> citizens.

No, this responsibility goes both ways. I, a user-agent provider, am
just as responsible as you to ensure good web citizenship. If hyper
connects to Jetty, does the ALPN handshake, and then finds a block
cipher has been negotiated, I am just as responsible as you for
tearing that connection down. The correct statement here is that "good
web citizens" are responsible for holding "bad web citizens" to
account.

I am confident that browsers will abide by the requirement in the
draft spec to tear down h2 connections to servers that don't negotiate
secure ciphers per 9.2.2. Everyone on this list will be working
together on this point (I hope). So the responsibility is not just for
you.

> But let's accept the premise that browser vendors are indeed morally corrupt
> and will deploy insecure ciphers rather than lose market share.

Why would anyone accept this premise? Especially with the loaded
language. I will accept a related premise: "browser vendors are
running businesses, and have an inclination to serve their own
financial best interests as well as the interests of their users". I
don't assume that *anyone* on this list is morally corrupt: I have
seen no evidence for this fact.

> Let's also
> assume that origin server deployers are also prepared to accept those bad
> ciphers and make their content available over them...  I have absolutely no
> idea how allowing those two to tango over http/1 rather than h2 pushes them
> to any better security practises.

It doesn't. None of the design goals I have ever seen for h2 include
making http/1 more secure. Why would they? And besides, what could the
spec possibly say? "If you negotiate h2 with insecure ciphers, tear
down the connection and refuse to ever allow connections from that
peer again"? If the connection fails, *clearly* a http/1 connection
can be made, so any ruling in the h2 spec does nothing to prevent what
you just discussed.

> Perhaps the failing abysmally to connect
> part might be a bit more persuasive, but I expect that is more likely to
> make them remove the good ciphers.

Yes it would. Again, server vendors want as many clients to be able to
connect to them as possible.

> If failure to connect is a driver to better cipher policy, then  we need not
> hobble h2 to achieve that.  Instead the browser vendors and server deployers
> can simply grow a pair and remove the bad ciphers.

Failing to connect is not a driver to good security policy, it's a
driver to *bad* security policy. Good security policy refuses
connections, bad security policy accepts them. And there will always
be pressure to make connections where others cannot. This is why
browsers let you browse to website with expired certs, it's why
libraries let you turn off certificate verification, and it's why
servers let you say you'll accept the TLS NULL cipher: because if they
don't, others will.

I don't think anyone in this list is a bad internet citizen because
we're all here trying to make it better! We've all got a vested
interest in the web being the best it can be. The problem is that us
taking the moral high ground leads to users picking up projects that
don't take the moral high ground. Absolutism here doesn't help anyone.
We have to work with what we've got. We have to be as secure as we can
be without driving users to implementations that don't care about
security.

Greg, I'm genuinely sympathetic to your original complaint. I've had
problem with cipher suites as well, and have accepted that the best I
can do is fail if the server screwed up. I don't like that approach.
But I think the goal of section 9.2.2 is laudable and I'd be loathe to
remove it without replacing it with something equally important.

Cory

---

From: Roland Zink <[email-masked]>
Date: Thu, 18 Sep 2014 11:20:43 +0200

I think the goal of section 9.2.2 is laudable. But I'm not sure if the 
layering is ok. When this is done within TLS, say with TLS 1.3, then the 
problem would vanish and the http2 layer wouldn't need to worry about it.

Roland

On 18.09.2014 10:33, Cory Benfield wrote:
> remove it without replacing it with something equally important. Cory

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 18 Sep 2014 19:44:08 +1000

Cory,

I accept that 'morally corrupt' was an overly flippant way to describe
commercial competition between implementations that may drive less than
secure choices (and again I don't think browser vendors are doing a
particular bad job on that front - it was a hypothetical acceptance of the
premise).

But competition also exists between servers and protocols.  If using a
server that provides h2 or switching h2 on results in connection failures
then users are going to use other servers or switch off h2.  That is hardly
an incentive for h2 adoption.

You suggest that jetty is going to be a bad web citizen by not implementing
9.2.2.  That is not the case, I very much would like to implement 9.2.2 and
but I cannot see how I can do that in a future proof and/or portable way.
Jetty runs on every thing from mobile pones to ancient main frames, so I
have a wide range of platforms that I need to be concerned about.   For now
I'm probably going to go with some hard coded regex that will approximate
the restriction for todays popular ciphers, but that's just a timebomb that
will wait until millions of implementations are deployed with differing
implementations of 9.2.2 and then a new cipher will detonate the bomb!

If it is really necessary to discriminate between which ciphers are
acceptable for which protocols, then ALPN needs to be enhanced so the
client can communicate it's list of h2 acceptable ciphers to the server, as
even the best faith attempt of the server to implement 9.2.2 will
eventually guess wrong and connection failure will occur.    9.2.2 may be
laudable, but it is unimplementable in any robust future proof way.  At the
very least it needs to specify a proper fallback/retry mechanism for if the
client and server disagree on acceptable ciphers.

I have still not heard how a new cipher like my hypothetical XYZ could be
deployed into a web where the current 9.2.2 is widely implemented.

regards

On 18 September 2014 18:33, Cory Benfield <[email-masked]> wrote:

> are
> corrupt
> not

---

From: Patrick McManus <[email-masked]>
Date: Thu, 18 Sep 2014 10:03:35 -0400

Hi Greg,

This thread is suffering a bit from wall-of-text syndrome for me. Is this
the main point below?

> know it is OK but some don't, then we have connection failure.
The scenario as I understand it is:
1] some new XYZ is in fact h2 appropriate by 9.2.2,
2] a client handshake offers both XYZ and GCM along with h2 and h1
3] the server selects XYZ+h2 (which meet the requirements of h2 - good job)
4] The client's h2 stack, expecting GCM, is not aware that XYZ satisfies
9.2.2 so it generates an h2 INADEQUATE_SECURITY

I would say that's an implementation bug in the client.

I think its an interesting editorial point to call out that you really do
need to understand the properties of the ciphers you offer to negotiate
because of the constraints of 9.2.2 - at least along the dimensions that
9.2.2 deals with.

> protocol+cipher combination.
Implementations (and I think this applies equally to clients and servers)
are buggy if they generate INADEQUATE_SECURITY on connections that meet the
requirements of 9.2.2. This is not impossible to do right because the
negotiation is always an intersection of the things the client and server
both know. I acknowledge that some languages and frameworks will need more
work than others to satisfy it - I don't find that an especially important
argument in this context as we've already included requirements that
require significant changes to existing widely deployed frameworks (e.g.
ALPN).

> connectivity with FF because it has implemented the GCM restriction before

I read this as you've had some interop problems because of buggy pioneer
implementations and evolving draft requirements - imo that's to be expected
at this stage of the process, not something to worry about maximizing
compatibility with. if the Java 7 app wasn't using an AEAD algorithm with
h2 then it was buggy, just like the old firefox nightlies that would allow
h2 to be negotiated with non-aead suites were buggy (I don't say that
pejoratively - bugs are just par for the course at this stage, its just
compatibility with buggy draft-level implementations doesn't really need to
be a constraint on the protocol definition.)

-P

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 18 Sep 2014 08:41:59 -0700

I still don't believe that any of these requirements belong in h2,
and I won't implement them even if they end up in the RFC.  It is
not the HTTP server's responsibility to second-guess the configuration
regarding the security properties of the underlying connections.
We have no idea what hardware or gateways might be doing to secure those
connections.  We don't even know what TLS library is being used,
since all we see is an API into someone else's code.

TLS requirements belong in the TLS code.

....Roy

---

From: Simone Bordet <[email-masked]>
Date: Thu, 18 Sep 2014 18:20:21 +0200

Hi,

> I would say that's an implementation bug in the client.

Any client that dynamically links the TLS implementation is subject to
this scenario, and certainly it's not an implementation bug in the
client if a deployer chooses to link that client to a newer TLS
library, no ?

Thanks !

---

From: Simone Bordet <[email-masked]>
Date: Thu, 18 Sep 2014 18:33:49 +0200

Hi,

On Thu, Sep 18, 2014 at 5:41 PM, Roy T. Fielding <[email-masked]> wrote:
> and I won't implement them even if they end up in the RFC.

As much as I would like to have 9.2.2 reworded to delegate to the TLS
spec, not implementing it on servers while all major browsers
implements it will result in a closed connection, no fallback and an
empty white page.
Not really good for HTTP/2, but alas.

Unfortunately there seems to be no way to make the editors change
their mind, so I am curious what kind of ripple effects do you foresee
by not implementing 9.2.2 as it currently stands.
We can weigh these effects and perhaps decide to not implement 9.2.2
in Jetty as well.

Thanks !

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 18 Sep 2014 10:56:41 -0700

> implements it will result in a closed connection, no fallback and an

No, it will just be left to the administrator to configure the right ciphers.
Doing that inside an application protocol is insane.

....Roy

---

From: Jason Greene <[email-masked]>
Date: Thu, 18 Sep 2014 13:10:33 -0500

> TLS requirements belong in the TLS code.

I agree. Although, I am sympathetic to the desire to establish conventions and sanity, but to me these things seem to apply to HTTP/1.1 just as much as HTTP/2. I am also sympathetic to clients that prefer to just work even in the face of poor security. So why not just display a warning when *anything* using TLS happens to pick a weak cipher. That will be just as motivating and far less error prone.

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

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 18 Sep 2014 21:48:47 +0300

> > I would say that's an implementation bug in the client.

Also, can happen the other way:

1) Client prefers XYZ (9.2.2 compliant, and client knows that) over GCM.
2) Client offers both ciphers (with XYZ first) and both h2 and h1.
3) Someone has added XYZ to server TLS stack, and it picks first one it
   supports (XYZ), or server even prefers XYZ.
4) There is version skew and server h2 stack doesn't probe TLS stack,
   so server h2 stack doesn't know about XYZ -> generates
   INADEQUATE_SECURITY.

> client if a deployer chooses to link that client to a newer TLS

Furthermore, if using some general-purpose TLS stack, like GnuTLS,
OpenSSL, LibReSSL, PolarSSL and couple others, such dynamic linking
is best practice.

I have seen version skew disabling features with both app and library
from autoupdate. And also distributors patching applications and
libraries for dynamic linking.

-Ilari

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 19 Sep 2014 09:32:22 +1000

> This thread is suffering a bit from wall-of-text syndrome for me. Is this

Sorry - my bad.   I understand that verbose repetition is not an adequate
response to perceived insufficient consideration of a concern.  Yet my
concern remains and it is a very significant one.    I believe that
deployment of 9.2.2  will hurt h2 adoption, hinder future good cipher
maintenance and will result in widespread future connection failures.

> The scenario as I understand it is:...

I would agree with you if 9.2.2 was written in precise language so that any
two implementations could be reasonable expected to arrive at the same
result now or into the future.  Currently I can find no definitive list of
acceptable AEAD modes. Wikipeadia lists : CCM
<http://en.wikipedia.org/wiki/CCM_mode>, GCM
<http://en.wikipedia.org/wiki/GCM_mode>, CWC
<http://en.wikipedia.org/wiki/CWC_mode>, EAX
<http://en.wikipedia.org/wiki/EAX_mode>, IAPM
<http://en.wikipedia.org/wiki/IAPM_mode>, and OCB
<http://en.wikipedia.org/wiki/OCB_mode>, but I don't think wikipeadia is a
sutiable reference for such things.    But even if such a list was
obtainable and even if we discount the possibility of AEAD being superseded
in the life of h2,   it is not clear if a h2 implementation is should
enforce this list with some form of name matching, or should it delegate
the decision to it's TLS layer via some isAE() API (and there is no
guarantee that such API will exist, specially for offloaded TLS).

But even if we call differing implementations of 9.2.2 a bug, it is a bug
that is very likely to occur and very likely to be repeated whenever
ciphers evolve. It a bug that has bad consequences.

> implementations and evolving draft requirements -
>

I understand that the problem at this stage is both expected and due to
jetty not yet implementing 9.2.2.  However, I raised this example as it
shows the consequence of differing interpretations of 9.2.2 is
communication failure rather than falling back to h1 or weaker ciphers.

If we make communication failure a likely consequence of differing/updating
security policies, then we are introducing significant disincentives for
good cipher maintenance in the future.

The reason for my wall of words is that unless somebody can point out the
flaw in my argument, the introduction of a new AEAD mode or the superseding
of AEAD itself is going to result in widespread communication failures
and/or fallback to h1

There are multiple possible solutions to address this concern in full or
part:

   - drop 9.2.2
   - rewrite 9.2.2 in more precise language (no 'such as')
   - have an IANA registry of 9.2.2 appropriate keys and a requirement to
   keep current
   - enhance ALPN that that is communicates acceptable ciphers for each
   protocol choice
   - have a fallback requirement so that connections are retried
   - require clients that offer h2 to only offer h2 acceptable ciphers
   - move 9.2.2 requirements to a document that applies to h1 and h2
   - show the flaw in my logic/scenarios

I prefer dropping 9.2.2 but would be happy to discuss other alternatives.
Instead I've mostly just been given programming advise as to how to make my
server pick the right cipher/protocol today so that the underlying issue of
differing implementations of 9.2.2 can be ignored.

---

From: Stuart Douglas <[email-masked]>
Date: Fri, 19 Sep 2014 10:57:21 +1000

I also think that this should not be in the HTTP2 spec, and looking the 
WG's HTTP2 charter I think that is explicitly listed as being out of scope:

Explicitly out-of-scope items include:
* Specifying the use of alternate transport-layer protocols. Note that 
it is expected that the Working Group will work with the TLS working 
group to define how the protocol is used with the TLS Protocol; any 
revisions to RFC 2818 will be done in the TLS working group.

Stuart

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 19 Sep 2014 07:55:48 +0200

> Doing that inside an application protocol is insane.

Totally agreed, and for haproxy it will certainly be the same, on both sides!

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 19 Sep 2014 08:08:09 +0200

On Thu, Sep 18, 2014 at 09:33:15AM +0100, Cory Benfield wrote:
> I, a user-agent provider, am

I disagree hre, only the admin knows in what context agents are deployed
and what security level is acceptable/accepted. Browser vendors have no
idea what usage is made from their product. If I'm using your browser to
retrieve photos from my low-level weather satellite in space for whom it's
extremely expensive to use higher crypto, it's *my* problem. And if I set
up an emergency server to cut the power in a datacenter using a 4096 bit
key and a cipher that is not supported by 9.2.2 because I feel it's more
secure than what is currently required, it's my decision as well.

I've always felt that the H2 spec is walking on the TLS group's feet here.
Inciting servers to increase their key length has always been done by cert
vendors, and browsers have always followed this support very early and this
model has been working for decades now. There's no reason for suddenly
breaking the net or making it harder to upgrade crypto there because the
algorithms are written black on white in the layer 7 protocol spec, which
also supports being transported over a clear medium!

Just like Roy, I won't implement any such control and will leave it to
the admin to configure the proper ciphers for this, because this is the
correct thing to do.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 19 Sep 2014 08:11:03 +0200

> of the now acceptable ciphers is no longer considered secure and should 

Simple response : it will not be possible to upgrade them anymore because
servers will have to change their cipher suite and become suddenly
incompatible with already deployed browsers. Updating the spec does not
mean upgrading all implementations at once... And advertising a new ALPN
name will not mean that servers will be able to propose a different cipher
suite depending on what protocol version is selected.

> Doesn't this cipher selection belong into TLS and not h2?

Sure!

Willy

---

From: Cory Benfield <[email-masked]>
Date: Fri, 19 Sep 2014 07:29:45 +0100

> secure than what is currently required, it's my decision as well.

This is a good point. As it turns out I'm covered because I will have
a switch that says "please stop bugging me about ciphers". This will
continue to allow you to do what you want, while having a by-default
behaviour that matches the RFC. Secure-by-default is almost always
better than secure-by-opt-in.

> also supports being transported over a clear medium!

I hadn't considered this, but I agree with this point.

Don't mistake my previous post for an impassioned defense of 9.2.2 in
its current form. I think its *goal* is laudable, not necessarily its
implementation, and if we think we can move the requirement (or
something similar) to the TLS WG I am happy to remove 9.2.2 from the
draft.

Cory

---

From: Stuart Douglas <[email-masked]>
Date: Fri, 19 Sep 2014 16:31:51 +1000

> the admin to configure the proper ciphers for this, because this is the

For what it is worth I also won't be implementing this in 
Undertow/Wildfly, and leaving it up to the admin to control the allowed 
cyphers. If this unfortunate clause does make it into the final spec 
then I may introduce some kind of strict option that makes a best effort 
guess as to what protocols should be allowed (which on Java 7 will be zero).

Another thing I really don't like about this section that Greg has 
already alluded to is that is assumes that 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 will remain a strong and unbroken 
cypher for the life of the HTTP2 spec. If this spec has anywhere near 
the longevity of HTTP1 there is a non zero chance this will not be true.

Stuart

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 19 Sep 2014 20:19:41 +1200

On 19/09/2014 6:29 p.m., Cory Benfield wrote:
> On 19 September 2014 07:08, Willy Tarreau wrote:
>> I disagree hre, only the admin knows in what context agents are
>> deployed and what security level is acceptable/accepted. Browser
>> vendors have no idea what usage is made from their product. If
>> I'm using your browser to retrieve photos from my low-level
>> weather satellite in space for whom it's extremely expensive to
>> use higher crypto, it's *my* problem. And if I set up an
>> emergency server to cut the power in a datacenter using a 4096
>> bit key and a cipher that is not supported by 9.2.2 because I
>> feel it's more secure than what is currently required, it's my
>> decision as well.
> 
> This is a good point. As it turns out I'm covered because I will
> have a switch that says "please stop bugging me about ciphers".

If some middleware is "the client" obeying HTTP/2 and rejecting all
communication due to 9.2.2 that switch has no relevance.

Amos

---

From: Cory Benfield <[email-masked]>
Date: Fri, 19 Sep 2014 10:24:59 +0100

> communication due to 9.2.2 that switch has no relevance.

Assuming I've understood you correctly this cannot be fixed without
removing 9.2.2. Any middleware that very strictly holds to 9.2.2 is
going to cause problems for clients/servers that do not.

---

From: Andrei Popov <[email-masked]>
Date: Sat, 20 Sep 2014 00:08:07 +0000

The HTTP/2 spec’s restrictions on the TLS versions and cipher suites creates a number of issues:
a) TLS code needs to filter ALPN IDs based on the negotiated TLS protocol version and cipher suite, or the HTTP stack needs to filter cipher suites and TLS protocol versions based on the enabled HTTP versions.
b) The server's security policy (e.g. allowed TLS protocol versions and cipher suites) is coupled to the supported HTTP versions. System admin cannot change these (seemingly orthogonal) things independently.
c) HTTP/2 spec needs to be updated when new secure cipher suites/TLS protocol versions are added, or currently available ones become compromised.

I understand the desire to use HTTP/2 as an opportunity to push the world to use more secure TLS versions and cipher suites, but creating interop issues for HTTP/2 users is not the best way to get there.

Cheers,

Andrei

From: Roland Zink [mailto:[email-masked]]
Sent: Wednesday, September 17, 2014 1:45 AM
To: [email-masked]
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

So how are new ciphers added later? Does this require a new HTTP2 RFC, or a new TLS RFC or do they need to be registered with IANA? What if one of the now acceptable ciphers is no longer considered secure and should be disabled?

Regards,
Roland

On 17.09.2014 07:44, Greg Wilkins wrote:
I have opened https://github.com/http2/http2-spec/issues/612 because this issue has not been resolved enough for me to understand enough to implement a working solution.
As well as my concern regarding the required capabilities of ALPN, I am struggling to work out how to implement 9.2.2 and I think there are going to be interoperability problems into the future. Specifically I think it will become impossible for a client to ever exclude a cipher from h2 acceptability without risking communication failure.
The basic problem occurs if ever the client and server disagree on exactly what is a h2 acceptable cipher.  The flow of the problem is:

  1.  Client offers connection with a set CLIENT_OK_CIPHER which is the union of CLIENT_OK_TLS_CIPHERS and CLIENT_OK_H2_CIPHERS
  2.  The server only sees the union set, so it does not know what ciphers the client think are h2 acceptable.  The server wants h2, so it picks a cipher from the intersection of CLIENT_OK_CIPHERS and SERVER_OK_H2_CIPHERS
  3.  If SERVER_OK_H2_CIPHERS != CLIENT_OK_H2_CIPHERS then a cipher may be picked that server thinks is h2 OK, but the client rejects because of it's interpretation of 9.2.2 at that time in the future.
  4.  The client and server fail to communicate even though they have ciphers and protocols in common!

The only way to avoid this problem is for the client and server to absolutely agree on what ciphers are h2 OK for all time and never ever ever EVER disagree.     This might be possible if 9.2.2 is rigorously written in a future proof way, but it is not:

So currently AES_128_CBC is an unacceptable h2 block cipher, but AES_128_GCM is accepted.   Do I hard code that AES_128_CBC is unacceptable or that AES_128_GCM is acceptable? If GCM is acceptable now, will GCM2 be acceptable in the future?  As written this clause does allow for future block ciphers with AEAD modes, but I don't know what they are in advance, so I can't hard code them?  Will there ever be acceptable block ciphers that use something other that AEAD?

Don't hard code I hear you say??? use a black/white list?????   Sure that allows both client and server to future proof their users interpretation of 9.2.2, but that is now just subjective configuration and there is absolutely no way that that client and servers will maintain the same h2 acceptable black/white lists.  If a client ever excludes a cipher from it's h2 acceptable set before a server has, then communication failure will result, even though client and server share acceptable ciphers and protocols!
In short, to avoid communication failure, the server either has to just use http/1 or it has to be absolutely sure it knows precisely what ciphers are h2 acceptable to the client.   I am unable to implement that kind of future proof telepathy and making it a configurable set just gives somebody else the impossible task of knowing what is client h2 acceptable.
regards

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 20 Sep 2014 19:40:54 +0300

On Sat, Sep 20, 2014 at 12:08:07AM +0000, Andrei Popov wrote:
> a) TLS code needs to filter ALPN IDs based on the negotiated TLS 
> protocol version and cipher suite, or the HTTP stack needs to filter
> cipher suites and TLS protocol versions based on the enabled HTTP
> versions.

The TLS protocol versions is not a problem, at least in no-MITM
environment: The application knows if it is trying TLS 1.2+ or
not. And I really hope that there is no TLS stack retarded enough
to fallback behind app's back.

Also, the server knows if it supports TLS 1.2+ or not. And if client
and server is TLS 1.2 capable, the negotiated version will be TLS
1.2.

However, things can go badly if there is some TLS MITM (some "security"
products apparently MITM TLS connections) in the middle (but still 
passes ALPN). Then the client and server assumptions turn badly
wrong.

The cipher requirements do have the shortcomings you note.

The PFS requirement is in the middle. It is feasible to just disable
all non-compliant ciphersuites globally (for server). And version
skew is unlikely, because new general-purpose PFS key exchanges are
extremely rare.

> c) HTTP/2 spec needs to be updated when new secure cipher suites/
> TLS protocol versions are added, or currently available ones become
> compromised (and special-purpose ones must be specifically enabled).

The HTTP/2 spec itself only needs update if AES falls, whole ECC
falls, RSA falls, or some new TLS version makes the specified MTI
unusable.

New ciphers (even "XYZ" ones) or TLS 1.3 do not require update
(but TLS 1.3 introduces a new failure mode: If client is TLS 1.2-
capable, and server is TLS 1.3-only, things are going to fail.
But that failure would happen with any protocol).

However, there is significant risk of version skew between the
application and TLS stack. This can lead to app making incorrect
decisions regarding cipher acceptability, with nasty consequences.

-Ilari

---

From: Andrei Popov <[email-masked]>
Date: Sat, 20 Sep 2014 18:10:32 +0000

> environment: The application knows if it is trying TLS 1.2+ or not. And I really hope that there is no TLS stack retarded enough to fallback behind app's back.

If a client offers TLS1.0 with h2 and http/1.1 ALPN IDs, a compliant server must not negotiate h2. So either the HTTP stack has to disable TLS<1.2 when h2 is enabled, or the TLS stack has to know to ignore h2 ALPN ID when the client offers TLS<1.2. Am I missing something?

> It is feasible to just disable all non-compliant ciphersuites globally (for server).

Yes, it is technically feasible to disable the TLS versions and cipher suites prohibited by h2 when h2 is enabled. This may also be the right way to improve security: http/1.1 is not any more secure than h2 when used with old TLS versions and weak cipher suites. But doing so will cut off the customers who were previously able to connect with TLS 1.0 and RSA-CBC, so I doubt that most Web servers are ready to do this.

> The HTTP/2 spec itself only needs update if AES falls, whole ECC falls, RSA falls, or some new TLS version makes the specified MTI unusable.

Yes, any of these conditions and a variety of other conditions will require an HTTP/2 spec revision. E.g. once our perception of the security of certain ephemeral key lengths, AEAD mode, specific cipher suite (TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256), or P256 curve will change, HTTP/2 spec will need an update. Previously these types of considerations were handled (admittedly, less than perfectly) by TLS specs. Now the HTTP/2 spec will also have to track this, which seems like a step in the wrong direction.

Cheers,

Andrei

-----Original Message-----
From: Ilari Liusvaara [mailto:[email-masked]] 
Sent: Saturday, September 20, 2014 9:41 AM
To: Andrei Popov
Cc: Roland Zink; [email-masked]
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

The TLS protocol versions is not a problem, at least in no-MITM
environment: The application knows if it is trying TLS 1.2+ or not. And I really hope that there is no TLS stack retarded enough to fallback behind app's back.

Also, the server knows if it supports TLS 1.2+ or not. And if client and server is TLS 1.2 capable, the negotiated version will be TLS 1.2.

However, things can go badly if there is some TLS MITM (some "security"
products apparently MITM TLS connections) in the middle (but still passes ALPN). Then the client and server assumptions turn badly wrong.

The PFS requirement is in the middle. It is feasible to just disable all non-compliant ciphersuites globally (for server). And version skew is unlikely, because new general-purpose PFS key exchanges are extremely rare.

> c) HTTP/2 spec needs to be updated when new secure cipher suites/ TLS 
> protocol versions are added, or currently available ones become 

The HTTP/2 spec itself only needs update if AES falls, whole ECC falls, RSA falls, or some new TLS version makes the specified MTI unusable.

New ciphers (even "XYZ" ones) or TLS 1.3 do not require update (but TLS 1.3 introduces a new failure mode: If client is TLS 1.2- capable, and server is TLS 1.3-only, things are going to fail.
But that failure would happen with any protocol).

However, there is significant risk of version skew between the application and TLS stack. This can lead to app making incorrect decisions regarding cipher acceptability, with nasty consequences.

-Ilari

---

From: "Roy T. Fielding" <[email-masked]>
Date: Sat, 20 Sep 2014 11:54:14 -0700

As a concrete example, almost all software and firmware updates are delivered
these days using HTTP (preferably over TLS, of course).  These sites are expected
to deliver updates to systems running obsolete software.  In some cases,
software that hasn't been run at all for five or six years.

When such a site receives a request using an older, now less-secure cipher,
but one that is expected for that type of client, what is the site supposed
to do?  Is it supposed to reject the request if the (perhaps updated) h2
specification says so?  Who does that help?  Obviously, the purpose of the
site is more important than the bad assumptions in 9.2.2.  That's why it
is an admin decision, not a protocol requirement.

There is a reason that TLS doesn't forbid the use of old ciphers, even the
ones that are known to be easily breakable.  Not every application is the
same.  We have BCP documents to explain the nuances of various choices.
When a site chooses to do something against BCP, it is usually because
they either have no idea how TLS is configured (in which case TLS should
be the one selecting the better defaults) or they have deliberately
chosen to configure it for the sake of their own, perhaps unique,
interoperability requirements.  We don't know which.  We don't know why.
And we sure as hell don't know when.

....Roy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Sep 2014 09:18:31 -0700

I don't have a really strong feeling on whether HTTP should mandate
specific TLS
ciphers, but I'd like to address a few technical points below.

On Thu, Sep 18, 2014 at 4:32 PM, Greg Wilkins <[email-masked]> wrote:

> I would agree with you if 9.2.2 was written in precise language so that
> any two implementations could be reasonable expected to arrive at the same
> <http://en.wikipedia.org/wiki/OCB_mode>, but I don't think wikipeadia is
> a sutiable reference for such things.
>

I don't think this is a real concern: TLS clearly categorizes every
algorithm that is added;
in fact this is a requirement since AEAD records are processed differently.
So the
relevant CipherSuite specification in fact does document whether a cipher
is AEAD
or not. Moreover, implementations need to know this so they can perform the
record
processing correctly. See, for instance:

http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/ssl3con.c#2597

>    But even if such a list was obtainable and even if we discount the
> possibility of AEAD being superseded in the life of h2,
>

I don't actually think this is that important an issue either. As I
understood the discussion
in Zurich, the new TLS limitations were directed towards pulling users of
HTTP2 towards
modern algorithms. However, algorithms which have serious weaknesses should
probably
be deprecated in all versions of HTTP (as with
https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-00).

Say we decided that in future we preferred Aero (
https://tools.ietf.org/html/draft-mcgrew-aero-01)
to AEAD constructions. That seems like something we could roll out in HTTP3
but wouldn't
be appropriate to retroactively apply to TLS 1.2 unless there was something
seriously wrong
with AEAD (and then see above).

 it is not clear if a h2 implementation is should  enforce this list with
> some form of name matching, or should it delegate the decision to it's TLS
> layer via some isAE() API
>

IMO it should ask the TLS layer about specific properties, not do name
matching.
That seems like a generally good API-use policy.

(and there is no guarantee that such API will exist, specially for
> offloaded TLS).

An offloaded TLS stack would presumably have to implement this internally,
since
it has to know whether it's safe to negotiate h2 at all.

-Ekr

---

From: Jim Manico <[email-masked]>
Date: Mon, 22 Sep 2014 12:30:23 -0400

I'm thinking about the safely of users....

Today, TLS can support the null cipher or painfully weak ciphers and the user is none the wiser. 

Some indicator of the strength of the current TLS connection or some standard where TLS connections with painfully weak ciphers are not allowed is critical to a secure future.

Aloha,
--
Jim Manico
@Manicode
(808) 652-3805

> On Sep 22, 2014, at 12:18 PM, Eric Rescorla <[email-masked]> wrote:
> 
> I don't have a really strong feeling on whether HTTP should mandate specific TLS
>>> This thread is suffering a bit from wall-of-text syndrome for me. Is this the main point below?
>> 
>> Sorry - my bad.   I understand that verbose repetition is not an adequate response to perceived insufficient consideration of a concern.  Yet my concern remains and it is a very significant one.    I believe that  deployment of 9.2.2  will hurt h2 adoption, hinder future good cipher maintenance and will result in widespread future connection failures.
>> 
>>  
>> I would agree with you if 9.2.2 was written in precise language so that any two implementations could be reasonable expected to arrive at the same result now or into the future.  Currently I can find no definitive list of acceptable AEAD modes. Wikipeadia lists : CCM, GCM, CWC, EAX, IAPM, and OCB, but I don't think wikipeadia is a sutiable reference for such things. 
> 
> I don't think this is a real concern: TLS clearly categorizes every algorithm that is added;
> in fact this is a requirement since AEAD records are processed differently. So the
> relevant CipherSuite specification in fact does document whether a cipher is AEAD
> or not. Moreover, implementations need to know this so they can perform the record
>>    But even if such a list was obtainable and even if we discount the possibility of AEAD being superseded in the life of h2,
> 
> I don't actually think this is that important an issue either. As I understood the discussion
> in Zurich, the new TLS limitations were directed towards pulling users of HTTP2 towards
> modern algorithms. However, algorithms which have serious weaknesses should probably
> be deprecated in all versions of HTTP (as with https://tools.ietf.org/html/draft-ietf-tls-prohibiting-rc4-00).
> 
> Say we decided that in future we preferred Aero (https://tools.ietf.org/html/draft-mcgrew-aero-01)
> to AEAD constructions. That seems like something we could roll out in HTTP3 but wouldn't
> be appropriate to retroactively apply to TLS 1.2 unless there was something seriously wrong
>>  it is not clear if a h2 implementation is should  enforce this list with some form of name matching, or should it delegate the decision to it's TLS layer via some isAE() API
> 
> IMO it should ask the TLS layer about specific properties, not do name matching.
>> (and there is no guarantee that such API will exist, specially for offloaded TLS).
> 
> An offloaded TLS stack would presumably have to implement this internally, since

---

From: Jason Greene <[email-masked]>
Date: Mon, 22 Sep 2014 11:41:22 -0500

> with AEAD (and then see above).

I think this hypothetical actually counters your point. Every rev of the HTTP spec introduces interop cost, therefore having to rev the protocol just because TLS needs to rev is unnecessary cost.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Sep 2014 10:29:41 -0700

On Mon, Sep 22, 2014 at 9:41 AM, Jason Greene <[email-masked]>
wrote:

> I think this hypothetical actually counters your point. Every rev of the
> HTTP spec introduces interop cost, therefore having to rev the protocol
> just because TLS needs to rev is unnecessary cost.

I think we're talking past each other here. There are two major cases:

- We're kind of sad that people use algorithm X and we wish they would
   do something more modern.
- There is something seriously wrong with algorithm X and people need
  transition off it pronto.

In the former case, we have pretty limited options, since it's probably not
worth breaking interop over. So, we can do nothing or we can gradually
tell people to upgrade at preexisting protocol upgrade points. I.e., we
wouldn't roll out HTTP3 to do this, we'd just do it when we were already
rolling out HTTP3 (the same way as 9.2.2 is now). in the second case,
we would want to adjust all versions of HTTP so no new rev would be
required.

-Ekr

-Ekr

---

From: Jason Greene <[email-masked]>
Date: Mon, 22 Sep 2014 12:44:36 -0500

On Sep 22, 2014, at 12:29 PM, Eric Rescorla <[email-masked]> wrote:

> 
> 
> On Mon, Sep 22, 2014 at 9:41 AM, Jason Greene <[email-masked]> wrote:
> 

Ok but then if you wait on HTTP/3, 9.2.2 then precludes your ability to select a more modern cipher category like the Aero example. So it doesn’t seem to really meet the former case, and it certainly doesn’t meet the latter.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 22 Sep 2014 11:21:52 -0700

On Mon, Sep 22, 2014 at 10:44 AM, Jason Greene <[email-masked]>
wrote:

> Ok but then if you wait on HTTP/3, 9.2.2 then precludes your ability to
> select a more modern cipher category like the Aero example. So it doesn’t
> seem to really meet the former case, and it certainly doesn’t meet the
> latter.

I don't think that's true. 9.2.2 doesn't say you can't do non-AEAD. It says
that you can't do stream or block. Rather:

"Clients MUST accept DHE sizes of up to 4096 bits. HTTP MUST NOT be used
with cipher suites that use stream or block ciphers. Authenticated
Encryption with Additional Data (AEAD) modes, such as the Galois Counter
Model (GCM) mode for AES <http://http2.github.io/http2-spec/#RFC5288>
[RFC5288] are acceptable."

I would assume that any new cipher spec would come with a "this is OK for
HTTP2" bit (or not). So I don't see the interop problem.

-Ekr

---

From: Jason Greene <[email-masked]>
Date: Mon, 22 Sep 2014 14:00:31 -0500

On Sep 22, 2014, at 1:21 PM, Eric Rescorla <[email-masked]> wrote:

> On Mon, Sep 22, 2014 at 10:44 AM, Jason Greene <[email-masked]> wrote:
> 
> 
> "Clients MUST accept DHE sizes of up to 4096 bits. HTTP MUST NOT be used with cipher suites that use stream or block ciphers. Authenticated Encryption with Additional Data (AEAD) modes, such as the Galois Counter Model (GCM) mode for AES [RFC5288] are acceptable."
> 

It does, but only for today. My wondering could be more precise though. In your hypothetical future example, AEAD is no longer “modern”, but Aero is. Until HTTP/3 is released, HTTP/2 at that time will not meet your first case [1], since AEAD would still be acceptable by the rules of 9.2.2. Granted, the TLS stack if recent in the future hypothetical can and should still pick Aero, just like it can and should pick AEAD today, without 9.2.2.

Put another way, 9.2.2 is a temporary social hack.

[1] "We're kind of sad that people use algorithm X and we wish they would do something more modern”

---

From: Simone Bordet <[email-masked]>
Date: Mon, 22 Sep 2014 21:50:58 +0200

Hi,

> we would want to adjust all versions of HTTP so no new rev would be

Frankly, I don't understand this at all.

HTTP 1.x was not "adjusted" when flaws have been found in ciphers.
Browsers and servers were just updated to pick up better ciphers, and
alert users otherwise
(http://blog.chromium.org/2014/09/gradually-sunsetting-sha-1.html).
Why we must now "adjust" HTTP/2 ?

If the HTTP/2 specification was delayed by enough time so that TLS 1.3
was already ratified, do you think it would have made sense to specify
9.2.2 as it is (rather than just requiring a SHOULD or MUST for TLS
1.3+) ?

Thanks !

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 23 Sep 2014 08:05:45 +1000

On 23 September 2014 03:29, Eric Rescorla <[email-masked]> wrote:

> I think we're talking past each other here.

Indeed that appears to be a problem when discussing complex issues such as
TLS.
Different opinions or levels of understanding can exist and that may result
in different implementations or at least different adoption rates.
When presented with that situation we should have a spec that will degrade
gracefully rather than just fail?   While I favour dropping 9.2.2 I have
suggested many other options that will avoid communication failure. Surely
those that think we should be making additional crypto requirements need to
come up with a proposal that does not result in communication failures?

Note that it may be true that the TLS implementation has full knowledge if
a cipher it is using is AEAD or not, but that does not mean that the h2
protocol above it can access that knowledge.     You suggest that in the
offloaded case, it is the TLS implementation itself that will have to know
h2's requirements for ciphers.  Isn't that entirely inverted logic?  Also
h2 might just be a carrier for yet another protocol (via a connect pipe),
if that protocol follows the precedent set here, the the TLS layer is going
to have to know the crypto requirements of protocols within protocols.

I think it is unworkable.... but let's follow our charter to determine if
it really is.  Our charter says that we should be coordinating the TLS
working group and let's see if they are happy to insist that TLS police
application protocol crypto requirements.

regards

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 22 Sep 2014 15:55:41 -0700

On 22 Sep 2014, at 3:05 pm, Greg Wilkins <[email-masked]> wrote:
> 
> I think it is unworkable.... but let's follow our charter to determine if it really is.  Our charter says that we should be coordinating the TLS working group and let's see if they are happy to insist that TLS police application protocol crypto requirements.

Greg, this was all done with deep involvement from the TLS WG; Eric was chair at the time, and now the document editor for 1.3.

There may be some mitigations we can introduce to make this easier for you. Dropping 9.2.2 isn’t on the table here — it’s been discussed for quite some time, with input from TLS and SECAREA, and has strong support. 

One thing that I’ve heard is requiring clients to offer the “good” suites first, to promote interop. Does anyone see a downside to doing that?

The other is making all of 9.2.2 (and maybe 9.2.1) specific to TLS 1.2; i.e., to let TLS 1.3 and beyond control their own destiny.

Regards (and about to get on a plane),

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

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 23 Sep 2014 09:40:47 +1000

On 23 September 2014 08:55, Mark Nottingham <[email-masked]> wrote:

> One thing that I’ve heard is requiring clients to offer the “good” suites
> first, to promote interop. Does anyone see a downside to doing that?

I really don't understand the process of last call and working code if when
an interop problem is discovered the response is that "it's all been
discussed before so no changes are possible"!

If 9.2.2 requirements are going to stay, then the client has to communicate
its interpretation of that clause to the server, rather than make the
server guess.   Ordering is insufficient as it just is a fragile approach
to try to hide the problem rather than resolve the problem.

Potentially ALPN needs to be extended so it can communicate which ciphers
are acceptable for which protocols.  Or some other mechanism needs to be
proposed that will allow identical simultaneous interpretations of 9.2.2
now and into the distant future.

The downside of requiring ordering is that it continues the wrong
assumption that the application protocol implementers have any
access/influence on the TLS implementation.  TLS is a different layer,
often with intermediary layers in between and frequently running on
different hardware.    If you want application protocols to be able to
participate in cipher negotiations, then you have to work on the standards
associated with TLS to ensure that such access is offered.       We are
already getting push back from the ALPN implementors in java8 that they do
not believe we should be involved in cipher selection.

Currently the only way to deploy h2 on java is to hack the JVM TLS
implementation.   That is a fragile temporary approach, but does allow me
to implement 9.2.2 at the moment.     However, for any wide deployment, I
need to restrict my server to using standard APIs and not doing hacks to
the bootloader of my VM.    The standard APIs only give me access to the
cipher as a name, so I fail to see how any name matching I do can keep in
lock step with the changing TLS implementations underneath the server.

regards

---

From: Jason Greene <[email-masked]>
Date: Mon, 22 Sep 2014 19:04:08 -0500

On Sep 22, 2014, at 6:40 PM, Greg Wilkins <[email-masked]> wrote:

> I really don't understand the process of last call and working code if when an interop problem is discovered the response is that "it's all been discussed before so no changes are possible”!

Well, isn’t consensus required to leave last call?

---

From: Patrick McManus <[email-masked]>
Date: Mon, 22 Sep 2014 20:20:45 -0400

On Mon, Sep 22, 2014 at 7:40 PM, Greg Wilkins <[email-masked]> wrote:

> interop problem is discovered

We don't have agreement that there is a problem here - your argument is
based around a world in which h2 doesn't know anything about the TLS
algorithms it is using and that just isn't how h2 is defined. Its expected
that frameworks will have some catching up to do - we've seen that progress
happen with ALPN already.

And to bump this up the stack a bit, this is really quite a useful
provision of h2. It is a waypoint for jettisoning stuff that we can't kill
for reasons of backwards compatibility (at least without a lot of pain) but
best practices tell us we shouldn't be using.

-P

---

From: Greg Wilkins <[email-masked]>
Date: Tue, 23 Sep 2014 12:10:08 +1000

Patrick,

The reality is that many h2 implementations will not have access to their
TLS layer in any meaningful way other than getting either a list of
available cipher names or the name of the selected cipher.   It does not
help us to deny that reality.

A server receives an array of ciphers from the client, let's say they are
well ordered so the h2 acceptable ones are at the front and the
unacceptable ones are at the end.  The server does not know where in that
list the browser has decided to make the break, so I can't just
mechanically remove the ciphers that my deployment thinks are unacceptable
and then select element [0].
(suggestion 1 - send separate cipher arrays for each protocol)

I have to re-evaluate each cipher myself to test if it is h2 acceptable and
I have to do so in a way that will always produce the same answers as the
client used, else I fail to connect. (suggestion 2 - define a retry
mechanism without unacceptable ciphers instead of just failing).

I may not have access to the local TLS implementation, so generally at best
all I have is the cipher name.   Sure I can come up with a regex that works
mostly today, using the wikipedia list of AEAD cipher names.   But such an
implementation will not change in lock step with the entire browser
population, so connection problems will result.  Even if I make the list
configurable, then that is still insufficient as if clients change their h2
acceptability list at different times, server configuration will have a
choice of not talking to a subset. .

If I have access to the TLS implementation, the questions I need to ask it
about the ciphers are not clear, as I doubt they have methods like
isBlockCipherButNotOneSuchAsGCM(). (suggestion 3 - improve the language in
9.2.2 to be more precise).  Also i am querying the server TLS impl which
may still differ from the client TLS impl.

regards

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 23 Sep 2014 07:42:55 +0200

Hi Eric,

On Mon, Sep 22, 2014 at 11:21:52AM -0700, Eric Rescorla wrote:
> > select a more modern cipher category like the Aero example. So it doesn???t
> > seem to really meet the former case, and it certainly doesn???t meet the
> > latter.
> 

I think it's not easy to tell what will exist in the future, however we can
exhaustively list what existing ciphers we don't want to support. Thus,
shouldn't we instead enumerate a list of properties that are incompatible
with HTTP/2 ? That would leave the door open for new ciphers. HTTP/1 has
benefitted from TLS evolutions for almost 20 years, and I would find it
sad that we have to emit a new HTTP version just to make everyone support
a new cipher. This is instead a property of the TLS layer and both sides
upgrade progressively to support new versions.

Regards,
Willy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Sep 2014 01:04:23 -0700

On Mon, Sep 22, 2014 at 12:00 PM, Jason Greene <[email-masked]>
wrote:

> Model (GCM) mode for AES [RFC5288] are acceptable."
> >
> It does, but only for today. My wondering could be more precise though. In
> your hypothetical future example, AEAD is no longer “modern”, but Aero is.
> Until HTTP/3 is released, HTTP/2 at that time will not meet your first case
> [1], since AEAD would still be acceptable by the rules of 9.2.2. Granted,
> the TLS stack if recent in the future hypothetical can and should still
> pick Aero, just like it can and should pick AEAD today, without 9.2.2.
>

That's my understanding of the situation, yes.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Sep 2014 01:06:43 -0700

On Sep 23, 2014 6:48 AM, "Willy Tarreau" <[email-masked]> wrote:

> with HTTP/2?

That is precisely what 9.2.2. does:

* MUST ephemeral

* MUST NOT block or stream cipher

The only other piece in 9.2.2 is dealing with the consequences of that.
SInce we prohibit the "MUST implement" suite in TLS 1.2, we defined a new
one so that we don't end up with mutually exclusive sets.

(Seems like every one is on a plane, one wonders if there is something
going on.)

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Sep 2014 01:11:16 -0700

> upgrade progressively to support new versions.

My understanding is that this is what 9.2.2 does.

-Ekr

Regards,

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Sep 2014 01:10:48 -0700

On Mon, Sep 22, 2014 at 3:05 PM, Greg Wilkins <[email-masked]> wrote:

> Different opinions or levels of understanding can exist and that may
> result in different implementations or at least different adoption rates.

I want to reemphasize at this point that I don't much care one way or the
other
whether HTTP2 requires AEAD. So, I'm trying to confine myself to discussing
the technical issues around the use of TLS.

With that said, I think there are two different situations here:

- People who misread the specification with the result that there are
interop
  failures.
- It not being in principle possible to avoid interop failures.

Based on your comments and whatever knowledge I currently have, I don't
believe that it's not possible to avoid interop failures. As I said,
implementations
can at least in principle distinguish which algorithms are acceptable and
which
are not and as long as we take some care not to change the rules
retroactively
I don't see why there should be an unsovlable interop problem.

It could well be the case that implementors will screw this up or are for
some
other reason unable to comply with 9.2.2, but that seems like a different
question.
Is that your sole concern or do you still believe that this will cause
interop problems
regardless of implementation correctness?

> h2's requirements for ciphers.  Isn't that entirely inverted logic?
>

Sorry, I'm not following. My point was merely that if you have an offload
device, it
is the place where the ALPN negotiation happens for HTTP2, so I'm not
following
why it can't do the conditional cipher suite negotiation at the same time.
What am I missing?

  Also h2 might just be a carrier for yet another protocol (via a connect
> pipe), if that protocol follows the precedent set here, the the TLS layer
> is going to have to know the crypto requirements of protocols within
> protocols.
>

Yes, if that protocol were negotiated via ALPN I think that would be true.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Sep 2014 01:15:49 -0700

> If a client offers TLS1.0 with h2 and http/1.1 ALPN IDs, a compliant server must not negotiate h2. So either the HTTP stack has to disable TLS<1.2 when h2 is enabled, or the TLS stack has to know t…

The draft permits the TLS stack to complete the negotiation.  That's
why we defined an INADEQUATE_SECURITY error code: for cases where the
stack proceeds.

> Yes, it is technically feasible to disable the TLS versions and cipher suites prohibited by h2 when h2 is enabled. This may also be the right way to improve security: http/1.1 is not any more secur…

No one is asking anyone to do that.  I don't consider it feasible to
ask a browser or server maker to cut out what turns out to be a
non-trivial proportion of their userbase, as it inevitably ends up
being.

> Yes, any of these conditions and a variety of other conditions will require an HTTP/2 spec revision. E.g. once our perception of the security of certain ephemeral key lengths, AEAD mode, specific c…

I don't consider this to be a problem any more than it is a problem
today with HTTP/1.1.  Which is, of course, understating the magnitude
of the problems with moving off old versions of TLS or bad
ciphersuites.  These things might not have widespread exploits, but
the vulnerabilities are a little beyond theoretical and we still can't
shift them.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Sep 2014 01:15:55 -0700

WRT to the process point, as Mark says there were  a number of TLS people
involved
in this discussion. I don't see a process problem with WGs profiling their
own TLS cipher
suites, though from a substantive perspective I would definitely hope that
they would
align them with the direction that TLS is going. That seems to have
happened here:
the cipher suites which are required in 9.2.2. are the ones the will be
permissible
for TLS 1.3.

Again, I don't really have a dog in this fight, and this might be a bad
idea for technical
or other reasons, but I don't believe there's a process problem.

-Ekr

On Mon, Sep 22, 2014 at 3:55 PM, Mark Nottingham <[email-masked]> wrote:

> > I think it is unworkable.... but let's follow our charter to determine
> if it really is.  Our charter says that we should be coordinating the TLS
> Greg, this was all done with deep involvement from the TLS WG; Eric was
> chair at the time, and now the document editor for 1.3.
>
> There may be some mitigations we can introduce to make this easier for
> you. Dropping 9.2.2 isn’t on the table here — it’s been discussed for quite
> some time, with input from TLS and SECAREA, and has strong support.
>
> The other is making all of 9.2.2 (and maybe 9.2.1) specific to TLS 1.2;
> i.e., to let TLS 1.3 and beyond control their own destiny.
>

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 23 Sep 2014 10:29:16 +0200

> My understanding is that this is what 9.2.2 does.

Maybe that's what it means for people who are expert in this area, but
when I read this for example :

   HTTP/2 MUST only be used with cipher suites that have
   ephemeral key exchange, such as the ephemeral Diffie-Hellman (DHE)
   [TLS12] or the elliptic curve variant (ECDHE) [RFC4492].

I'm not seeing exclusion of various broken things, just restriction to
a specific mode. Don't get me wrong, I'm clearly not skilled in this
area, and my unwise eye reads this as "must implement either DHE or
ECDHE". I don't know if right now there are alternatives that must be
avoided, just like I don't know when reading this if a future solution
will be acceptable or not. Thus my point was that it could be reworded
against the solutions that are not acceptable instead (if such exist).
For example :

   HTTP/2 MUST NOT be used with cipher suites that do not have ephemeral
   key exchange, such as XYZ.

Similarly, I'm seeing this :

   Clients MUST accept DHE sizes of up to 4096 bits.

This means to me that DHE must always be supported. What if in the
future we consider DHE not to be acceptable anymore ? There will be
a conflict. Isn't it better to say something like :

   Clients implementing DHE MUST accept sizes of up to 4096 bits.

(I don't know if there are alternatives to DHE).

And the last one :

   To avoid this problem, implementations of HTTP/2 that use
   TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
   [TLS-ECDHE] with P256 [FIPS186].

Is this the only acceptable cipher for TLS 1.2 or are there stronger
ones that are acceptable as well ? If the latter, the sentence above
forces avery implementation to support at least this one, even five
years away when we decide to obsolete it despite other ciphers still
being acceptable for TLS 1.2.

I know that the point is about ensuring that communications are made
over a reasonably safe channel, but for the unaware people configuring
the ciphersuite in their servers, it's really not easy to tell which
one is eligible and which one is not. All we know is that the ciphersuite
must at least include the examples above to ensure interoperability, but
we don't know if other ones are safe, just like we don't have any hints
what to chose when the ones above are obsoleted.

Maybe we could even have an exhaustive list in the spec of all the ciphers
that are not acceptable at the time of writing. This would significantly
help admins to validate their setups and refine the cipher suite if they
find them. Just a guess, I don't even know if that's possible to enumerate
them all.

Thanks,
Willy

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Sep 2014 01:30:11 -0700

On Mon, Sep 22, 2014 at 7:10 PM, Greg Wilkins <[email-masked]> wrote:

> I have to re-evaluate each cipher myself to test if it is h2 acceptable
> and I have to do so in a way that will always produce the same answers as
> the client used, else I fail to connect. (suggestion 2 - define a retry
> I may not have access to the local TLS implementation, so generally at
> best all I have is the cipher name.   Sure I can come up with a regex that
> works mostly today, using the wikipedia list of AEAD cipher names.   But
> such an implementation will not change in lock step with the entire browser

You've offered this argument a number of times, but I'm still not
understanding
how this happens. We have an existing list of ciphers which we can divide
along whether they are acceptable or not. I think the 9.2.2 language is
actually pretty clear but maybe I'm just too close to it. In any case, we
can certainly make it unambiguous even if that means listing every
cipher suite that is currently acceptable. In either case, client and
server should
agree for every existing cipher suite.

 This leaves us with two things that can cause disagreement.

- We might introduce a new cipher suite.
- We might retroactively reclassify an old one.

In the former case, we should identify whether new cipher suites are
acceptable.
This could either be by making them match the characteristics in 9.2.2
(PFS + AEAD) or by explicitly saying they are OK. In either case, when
implementations add these cipher suites, they should know if they are
acceptable so you shouldn't have disagreement.

This leaves us with retroactive reclassification. We shouldn't do that.

So, can you explain to me how client and server can disagree?

> may still differ from the client TLS impl.

FWIW, NSS does have this. Given a connection you do:

* SSL_GetChannelInfo() which returns a structure that contains the cipher
suite
identifier.

* SSL_GetCipherSuiteInfo() which returns an SSLCipherSuiteInfo:
http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslt.h#127

The MAC algorithm tells you whether it's of type AEAD:
http://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslt.h#149

-Ekr

---

From: Julian Reschke <[email-masked]>
Date: Tue, 23 Sep 2014 10:50:43 +0200

> The other is making all of 9.2.2 (and maybe 9.2.1) specific to TLS 1.2; i.e., to let TLS 1.3 and beyond control their own destiny.

That sounds like a good idea in any case (independently of whether it 
addresses Greg's concerns wrt TLS 1.2).

Best regards, Julian

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Sep 2014 02:16:24 -0700

> One thing that I’ve heard is requiring clients to offer the “good” suites first, to promote interop. Does anyone see a downside to doing that?

It would definitely solve Greg's issue with Java <= 7.

The only case where this wouldn't work is where clients are unable to
alter the priority order of cipher suites.  I don't know if any of
those exist; I haven't met one yet, though I anticipate an
introduction shortly...  The worst failure mode here results in a
fallback - once you discover that the server supports HTTP/2, you can
kill off the bad suites and try again.

That seems to be the only concrete technical concern I've seen raised
in the discussion.  I think that Eric has addressed most of the
process concerns.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Sep 2014 03:09:36 -0700

> addresses Greg's concerns wrt TLS 1.2).

Given that TLS have already agreed to make the same restrictions
(aside from mandatory to implement cipher suite) that 9.2.2 makes, I
see only upside to this.  The only restriction that seems like it
could be special is the SNI one, for which I will create a special
exclusion.

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

---

From: Roland Zink <[email-masked]>
Date: Tue, 23 Sep 2014 13:02:59 +0200

On 23.09.2014 10:30, Eric Rescorla wrote:
>
> On Mon, Sep 22, 2014 at 7:10 PM, Greg Wilkins <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Patrick,
>
>     The reality is that many h2 implementations will not have access
>     to their TLS layer in any meaningful way other than getting either
>     a list of available cipher names or the name of the selected
>     cipher.   It does not help us to deny that reality.
>
>     A server receives an array of ciphers from the client, let's say
>     they are well ordered so the h2 acceptable ones are at the front
>     and the unacceptable ones are at the end.  The server does not
>     know where in that list the browser has decided to make the break,
>     so I can't just mechanically remove the ciphers that my deployment
>     thinks are unacceptable and then select element [0].
>     I have to re-evaluate each cipher myself to test if it is h2
>     acceptable and I have to do so in a way that will always produce
>     the same answers as the client used, else I fail to connect.
>     (suggestion 2 - define a retry mechanism without unacceptable
>     ciphers instead of just failing).
>
>     I may not have access to the local TLS implementation, so
>     generally at best all I have is the cipher name. Sure I can come
>     up with a regex that works mostly today, using the wikipedia list
>     of AEAD cipher names.   But such an implementation will not change
>     in lock step with the entire browser population, so connection
>     problems will result.  Even if I make the list configurable, then
>     that is still insufficient as if clients change their h2
>     acceptability list at different times, server configuration will
>     have a choice of not talking to a subset. .
>
>
My attempt to explain the potential problem. There are two things 
negotiated by TLS. One is the upper layer protocol like HTTP1 / HTTP2 
and the other is the cipher. When the protocol specifies also a list of 
ciphers then these two decision are not independent.

For example the TLS library gets updated to support some new cipher Cn 
which it thinks is fine with h2. The client offers h1, h2 and some new 
protocol Pn and also a list of ciphers including Cn. The server only 
supports h1 and h2. Both together with Cn. Now the server selects Cn and 
h2. The client TLS layer is fine with this and gives it to the http2 
layer. The http2 layer fails the check as it isn't in its white list. So 
for TLS the connection succeeded but the client can't continue with h2.

Now say the API is a bit more elaborated and the TLS library client 
offer h1 with cipher set C1, h2 with C2 and Pn with C3. Only C1 and C3 
contain cipher Cn. The TLS client library does a union of the cipher 
sets and as Pn is the preferred protocol the Cn is up in the list of 
ciphers. The server choose h2 and Cn. Now again the client can't 
continue although it supports h2 and Cn. It even can't continue with h1 
as h2 was negotiated with ALPN.

If the client wants to be on the safe side then it can offer only the 
ciphers which are in all sets, but this set may be small or even empty. 
Especially this set may not include 
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 when Pn doesn't like it. On the 
server side TLS can't know which ciphers the client supports with which 
protocol.

Regards,
Roland

---

From: Michael Sweet <[email-masked]>
Date: Tue, 23 Sep 2014 05:01:46 -0700

Martin,

Apple's TLS implementation provides API to get/set the list of cipher suites but makes no guarantee or statement about the order being significant.  So to be honest I don't know whether the ~900 million iOS and OS X clients out there will be able to play the cipher suite games needed to opportunistically establish a HTTP/2 connection and gracefully fall back to HTTP/1.1 - will report back when I have something more definitive...

> On Sep 23, 2014, at 2:16 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Sep 2014 05:23:09 -0700

On Tue, Sep 23, 2014 at 4:02 AM, Roland Zink <[email-masked]> wrote:

>>  The reality is that many h2 implementations will not have access to
>> their TLS layer in any meaningful way other than getting either a list of
>>  A server receives an array of ciphers from the client, let's say they
>> are well ordered so the h2 acceptable ones are at the front and the
> negotiated by TLS. One is the upper layer protocol like HTTP1 / HTTP2 and
> the other is the cipher. When the protocol specifies also a list of ciphers
> then these two decision are not independent.
>
> h2. The client TLS layer is fine with this and gives it to the http2 layer.
> The http2 layer fails the check as it isn't in its white list. So for TLS
> the connection succeeded but the client can't continue with h2.
>

I see what you mean. I think clearly a conformant HTTP client is going to
need to configure
the TLS stack to suppress any ciphersuite it doesn't recognize.

Now say the API is a bit more elaborated and the TLS library client offer
> h1 with cipher set C1, h2 with C2 and Pn with C3. Only C1 and C3 contain
> cipher Cn. The TLS client library does a union of the cipher sets and as Pn
> is the preferred protocol the Cn is up in the list of ciphers. The server
> choose h2 and Cn. Now again the client can't continue although it supports
> h2 and Cn. It even can't continue with h1 as h2 was negotiated with ALPN.
>

Again, this seems like a "don't do that then" kind of situation.

-Ekr

---

From: Simone Bordet <[email-masked]>
Date: Tue, 23 Sep 2014 14:54:20 +0200

Hi,

> the TLS stack to suppress any ciphersuite it doesn't recognize.

How can the client do that if it does not even know what is the
protocol that the server will choose ?
The ciphers that would need to be suppressed for h2 may not need to be
suppressed for h1.
Along the lines reported by Michael Sweet for iOS, I have doubts that
JDK/Android implementations of TLS will offer much in this area, and
if they do it will take years.

> Again, this seems like a "don't do that then" kind of situation.

Can you expand on what you exactly mean here ?
The client has no idea what the server will choose so from the client
point of view everything is legal.
Had the server chosen Pn and Cn, everything would have worked fine, so
how can the client "don't do that" if the server chooses h2 ?

Thanks !

---

From: Andrei Popov <[email-masked]>
Date: Tue, 23 Sep 2014 18:00:32 +0000

Hi Martin,

> The draft permits the TLS stack to complete the negotiation.  That's why we defined an INADEQUATE_SECURITY error code: for cases where the stack proceeds.

How does this help? Basically, if the TLS layer does not filter ALPN IDs, or the HTTP layer does not filter TLS protocol versions/cipher suites/TLS extensions, then connections will sometimes fail with INADEQUATE_SECURITY errors? I don't think a general-purpose Web server can realistically go down this path.

> I don't consider it feasible to ask a browser or server maker to cut out what turns out to be a non-trivial proportion of their userbase, as it inevitably ends up being.

This is my point exactly:)

> I don't consider this to be a problem any more than it is a problem today with HTTP/1.1.  Which is, of course, understating the magnitude of the problems with moving off old versions of TLS or bad ciphersuites.  These things might not have widespread exploits, but the vulnerabilities are a little beyond theoretical and we still can't shift them.

I am in full agreement: it is hard to get the world to disable weak ciphers and old TLS versions. Right now addressing a new TLS vulnerability involves:
1. Updating TLS RFCs;
2. Patching TLS stacks;
3. Getting patched TLS stacks deployed. 

Requiring certain TLS versions and cipher suites in HTTP RFCs means that now we also need to:
4. Update HTTP RFCs when TLS vulnerabilities are discovered;
5. Patch HTTP stacks for TLS vulnerabilities;
6. Get patched HTTP stacks deployed.

So it seems that instead of keeping the problem encapsulated at the TLS layer and figuring out how to better solve it there, we're spreading it to the application layer. I think this would be counter-productive.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2014 1:16 AM
To: Andrei Popov
Cc: Ilari Liusvaara; Roland Zink; [email-masked]
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

> If a client offers TLS1.0 with h2 and http/1.1 ALPN IDs, a compliant server must not negotiate h2. So either the HTTP stack has to disable TLS<1.2 when h2 is enabled, or the TLS stack has to know t…

The draft permits the TLS stack to complete the negotiation.  That's why we defined an INADEQUATE_SECURITY error code: for cases where the stack proceeds.

> Yes, it is technically feasible to disable the TLS versions and cipher suites prohibited by h2 when h2 is enabled. This may also be the right way to improve security: http/1.1 is not any more secur…

No one is asking anyone to do that.  I don't consider it feasible to ask a browser or server maker to cut out what turns out to be a non-trivial proportion of their userbase, as it inevitably ends up being.

> Yes, any of these conditions and a variety of other conditions will require an HTTP/2 spec revision. E.g. once our perception of the security of certain ephemeral key lengths, AEAD mode, specific c…

I don't consider this to be a problem any more than it is a problem today with HTTP/1.1.  Which is, of course, understating the magnitude of the problems with moving off old versions of TLS or bad ciphersuites.  These things might not have widespread exploits, but the vulnerabilities are a little beyond theoretical and we still can't shift them.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 24 Sep 2014 04:27:22 +1000

> * MUST NOT block or stream cipher
but it also lists exceptions for ciphers like AES GCM, which is a block
cipher.   Also this language does not help you if all you have is the
cipher name.  Unless we create an IANA register of h2 (un)acceptable cipher
names

On 23 September 2014 19:16, Martin Thomson <[email-masked]> wrote:

> > One thing that I’ve heard is requiring clients to offer the “good”
> suites first, to promote interop. Does anyone see a downside to doing that?
>

Sorry but it does not help at all.   An ordered array with an undeclared
break between good and bad ciphers still needs the server to be able to run
an isAcceptableToH2 method to determine the break.  If I have that method,
then ordering is not necessary.

There are two problems here - one is the debate about if we should be doing
TLS restrictions in the first place.   The other is about designing a good
handshake.  Currently the handshake is not a good design and relies on
expected evolution of ciphers into the future an norms of configuration to
make it work.      If the spec at least designed a handshake that was
robust, I would be a lot less strident about my opposition to this social
engineering experiment.

regards

---

From: Jason Greene <[email-masked]>
Date: Tue, 23 Sep 2014 13:26:28 -0500

> So it seems that instead of keeping the problem encapsulated at the TLS layer and figuring out how to better solve it there, we're spreading it to the application layer. I think this would be count…

Indeed. Why not go with a gentler social hack that accomplishes a similar result? If user agents start warning about weaker ciphers, in a similar (yet gentler) way to certificate warnings, then server administrators will be motivated to update and/or configure their TLS stacks. This type of social hack would benefit all web protocols, not just http/2.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 24 Sep 2014 04:36:27 +1000

On 23 September 2014 18:30, Eric Rescorla <[email-masked]> wrote:

>
> You've offered this argument a number of times,
>

sorry for this.

> but I'm still not understanding
> how this happens.
>

which is why I keep repeating my attempt to explain it.

> acceptable so you shouldn't have disagreement.

No they can't.  Let's say a server has kept up to date with the latest h2
acceptable ciphers, as have the majority of browsers.       The server then
sees a handshake with the new XYZ cipher in it.  Because of the poor
handshake design, the server does not know if the client is offering XYZ as
a h2 acceptable cipher or simply because it was added to the clients cipher
list but the client has not yet been updated to know it is h2 acceptable -
and thus will reject a h2 connection that uses it.

If the answer to this is to make h2 clients not offer new ciphers provided
by their infrastructure until such time as their h2 impl is updated, then
9.2.2 will work in the opposite way to what is intended and will eventually
discourage adoption of new ciphers as it will require updates to
application protocols as well.

If we are to do social engineering of the cipher selection, can we at least
design a robust handshake.    Having clients hide information on the
assumption the server will work it out is just not a robust protocol design.

regards

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Sep 2014 13:12:55 -0700

On Tue, Sep 23, 2014 at 11:27 AM, Greg Wilkins <[email-masked]> wrote:

> cipher.

As far as TLS is concerned, AES-GCM is not a block cipher [0] It is an AEAD
cipher. This is pretty clear in the specification:

   This document describes the use of AES [AES
<https://tools.ietf.org/html/rfc5288#ref-AES>] in Galois Counter Mode
   (GCM) [GCM <https://tools.ietf.org/html/rfc5288#ref-GCM>] (AES-GCM)
with various key exchange mechanisms as a
   cipher suite for TLS.  AES-GCM is an authenticated encryption with
   associated data (AEAD) cipher (as defined in TLS 1.2 [RFC5246
<https://tools.ietf.org/html/rfc5246>])
   providing both confidentiality and data origin authentication.

https://tools.ietf.org/html/rfc5288#section-1

Also this language does not help you if all you have is the cipher name.
> Unless we create an IANA register of h2 (un)acceptable cipher names
>

I don't believe that this is correct. As I said earlier, TLS categorizes
ciphers
by type, and so once you have the ciphersuite definition you know if it's
block, stream, or aead.

-Ekr

> There are two problems here - one is the debate about if we should be
> doing TLS restrictions in the first place.   The other is about designing a
> good handshake.  Currently the handshake is not a good design and relies on

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Sep 2014 13:17:13 -0700

On Tue, Sep 23, 2014 at 11:36 AM, Greg Wilkins <[email-masked]> wrote:

> which is why I keep repeating my attempt to explain it
>

Thanks. I'll try to address your comments below.

> by their infrastructure until such time as their h2 impl is updated,
>

I think that this is how h2 clients must behave in order to make the
requirements
in 9.2.2 work. Can we agree that if h2 clients behave this way, that there
is not
an interop problem? I agree that it remains an open question what the
impact on
new cipher adoption will be.

 -Ekr

then 9.2.2 will work in the opposite way to what is intended and will
> eventually discourage adoption of new ciphers as it will require updates to

> If we are to do social engineering of the cipher selection, can we at
> least design a robust handshake.    Having clients hide information on the

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 24 Sep 2014 08:41:46 +1000

On 24 September 2014 06:17, Eric Rescorla <[email-masked]> wrote:

>> If the answer to this is to make h2 clients not offer new ciphers
>> provided by their infrastructure until such time as their h2 impl is
>> updated,
>>
>
> an interop problem?

We can definitely agree on this.   If the client does not offer a cipher
that it later rejects due to the protocol the server selects, then we do
not get this problem.

However, I'm not sure we can achieve that with any reasonable extension of
9.2.2

Firstly there is the practical problem that a lot of non browser clients
are administered with black lists rather than white lists.   So for example
a java client that is run on a new JVM is likely to have new ciphers.    So
at the very least we need to instil a cultural change to make such clients
white list instead.

But the bigger problem is that when offering a TLS connection, the client
may be offering it for h1, h2 and spdy.   Thus this way out of the 9.2.2
interop problem will mean that clients will not be able to take advantage
of the latest greatest ciphers for h1

I agree that it remains an open question what the impact on
> new cipher adoption will be.

Indeed.  Waiting until h2 implementations officially white list ciphers is
going to be a hindrance to the adoption of new ciphers for h1, spdy and any
other protocols negotiated over ALPN.      If this really is something we
want to do, then I repeat my suggestion that we look at extending ALPN so
that it communicates the cipher sets for each protocol.

But generally, seeing that TLS connections are negotiated for both h1 and
h2, I think the correct place for new cipher policies to be advanced is in
an update of rfc2818 and/or rfc7301 rather than in this draft.

cheers

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Sep 2014 23:02:33 -0700

Sorry about the long reply.  Too many words have been spent on this
topic already, but I think that Andrei's comments go to the core of
what is an important issue.

> How does this help? Basically, if the TLS layer does not filter ALPN IDs, or the HTTP layer does not filter TLS protocol versions/cipher suites/TLS extensions, then connections will sometimes fail…

This helps because it allows people who don't have the ability to
alter the TLS negotiation process to determine whether things have
succeeded.  It's primarily useful for clients though, where the client
determines that TLS has completed, but the server chose RC4 rather
than something that is actually good.

A server probably shouldn't be doing this, unless it is implemented on
top of something like Java 7 and the set of suites that the client
offered caused the stack to pick a bad suite.

The idea is to limit what HTTP/2 (and HTTP/1.1 in combination)
requires of the TLS stack.  At this point, the following control
points are required:

1. set what cipher suites are enabled
2. on the client, set the order that cipher suites are offered
3. determine what cipher suite has been negotiated

If we didn't provide INADEQUATE_SECURITY, then we would require a
greater level of control, the likes of which Greg thinks we need
maybe.

> So it seems that instead of keeping the problem encapsulated at the TLS layer and figuring out how to better solve it there, we're spreading it to the application layer. I think this would be count…

To reuse ekr's taxonomy, there are two levels of problem we worry about here:

1. Events where a suite turns out to have a disastrous flaw.  This is
a chemical spill situation and we will have to use disaster recovery
measures, which might be drastic.  I don't see a particular burden in
having to update application usages as well as the core of TLS for a
disaster like that.

2. The harder problem is the slow rot of ciphers that are simply in
the process of becoming obsolete.  This is what has motivated this set
of requirements.  If HTTP/2 is never negotiated with RC4, that
wouldn't be a bad thing.

I do want to call you out on the basic argument you are relying on
here, which I think is flawed.  You seem to assume that we are not
entitled to demand certain features of the TLS stack.  That the TLS
stack is the one place that this sort of knowledge is enshrined.  I
apologize here if I seem to have misrepresented your argument as an
appeal to authority, that's not what I intend.

My interpretation of things here is that an application is able to
demand a certain minimum level of protection.  More correctly, I
believe that it is the responsibility of an application to make that
demand.  I choose to interpret the existence of efforts like UTAas an
indication that this is the institutional belief of the IETF, but will
let others reach their own conclusions on that.

On the specifics of this matter, I don't think that there is any
question that we are entitled to require that packets be encrypted,
rather than using a suite like say TLS_RSA_WITH_NULL_SHA, which
doesn't encrypt at all.  And as a practical matter, the difference
between that and something as weak as TLS_RSA_WITH_DES_CBC_SHA is
pretty much academic.  Maybe that distinction matters more to you, but
I contend that practicality rules here.

Similarly, I believe that is well within our rights to request a suite
that can offer forward secrecy.

If you accept that premise, then I think the only question is where
the line is drawn.  The AEAD distinction is merely a convenient
delineation point, being new enough to ensure that only relatively
modern ciphers are accepted and old ones are not.  It also
intentionally aligns with the choices made for TLS 1.3.

An alternative is to exhaustively enumerate the entries from the
registry that we don't want, which I am also OK with.  I'm not sure
that this changes the set of codecs.  And if we moved the line to
permit a block cipher, the question of whether to permit the EtM
variant only comes up.

I understand why you might reject this premise, I really do.  And this
is a point that we may just end up disagreeing on, even if we can
agree about the facts, which have at times been victim to rhetoric in
this debate.

I just think that the choices we've made improve security at a
holistic level, and that's what I care about most.  If we do nothing,
then we've lost an opportunity, and that would be disappointing.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Sep 2014 00:02:18 -0700

On Tue, Sep 23, 2014 at 3:41 PM, Greg Wilkins <[email-masked]> wrote:

>> in 9.2.2 work. Can we agree that if h2 clients behave this way, that
>> there is not
>> an interop problem?
>>
>

[Removing the rest of your message since I'm just trying to focus
on the technical issue.]

I'm sorry, I'm not following this point.

Say that someone invents some new cipher suite, X. It's either
acceptable for h2 or it's not [0]. The client then behaves as follows:

- If it is acceptable for h2, the client offers it, since everything is
  fine.
- If it's not acceptable for h2, the client offers it, secure in the
  knowledge that a conformant server will (per 9.2.2) not negotiate
  it for h2.

As far as I can tell, either of these is fine. Do you disagree?

The only case that seems problematic is if the client doesn't know if
it's acceptable. This can only really happen in cases where the HTTP
stack and the TLS stack have an arms length relationship, since
otherwise the implementor can just read the spec and see whether it's
acceptable or not. In that case, the client must do either one of two
things:

- Not offer the cipher suite (with the result that it takes a long time for
  such clients to get access to the latest cipher suite.)
- Offer it and proceed with h2 if it's negotiated (potentially in violation
  of 9.2.2).

Neither of these should lead to interop failure. What am I missing.

-Ekr

[0] I think it's fairly unlikely we would deliberately standardize a new
cipher suite that didn't work for h2 at this point, but that's a side
issue.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Sep 2014 00:05:17 -0700

On 23 September 2014 11:27, Greg Wilkins <[email-masked]> wrote:
> cipher.   Also this language does not help you if all you have is the cipher
> name.  Unless we create an IANA register of h2 (un)acceptable cipher names

GCM is an AEAD cipher.

> then ordering is not necessary.

Of course it works.  A Java (<=7) server picks the first suite that it
supports from the list offered by the client.  An h2 compliant client
is required to offer at least one valid suite that an h2 compliant
server is required to support, so this can't possibly result in a
"bad" suite being selected.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 24 Sep 2014 19:44:18 +1200

On 24/09/2014 7:02 p.m., Eric Rescorla wrote:
>>>> If the answer to this is to make h2 clients not offer new
>>>> ciphers provided by their infrastructure until such time as
>>>> their h2 impl is updated,
>>>> 
>>> 
>>> I think that this is how h2 clients must behave in order to
>>> make the requirements in 9.2.2 work. Can we agree that if h2
>>> clients behave this way, that there is not an interop problem?
>>> 
>> 
>> We can definitely agree on this.   If the client does not offer a
>> cipher that it later rejects due to the protocol the server
>> selects, then we do not get this problem.
>> 
>> However, I'm not sure we can achieve that with any reasonable
>> extension of 9.2.2
>> 
>> Firstly there is the practical problem that a lot of non browser
>> clients are administered with black lists rather than white
>> lists.   So for example a java client that is run on a new JVM is
>> likely to have new ciphers.    So at the very least we need to
>> instil a cultural change to make such clients white list
>> instead.
>> 
>> But the bigger problem is that when offering a TLS connection,
>> the client may be offering it for h1, h2 and spdy.   Thus this
>> way out of the 9.2.2 interop problem will mean that clients will
>> not be able to take advantage of the latest greatest ciphers for
>> h1
>> 
> 
> acceptable for h2 or it's not [0].

You are looking at this wrong. The variants are:

 known acceptible       - 9.2.2 works
 known unacceptible     - 9.2.2 rejects
 unknown acceptible     - 9.2.2 rejects!!
 unknown unacceptible   - 9.2.2 rejects

> The client then behaves as follows:
> 
> - If it is acceptable for h2, the client offers it, since
> everything is fine. - If it's not acceptable for h2, the client
> offers it, secure in the knowledge that a conformant server will
> (per 9.2.2) not negotiate it for h2.
> 
> The only case that seems problematic is if the client doesn't know
> if it's acceptable. This can only really happen in cases where the
> HTTP stack and the TLS stack have an arms length relationship,
> since otherwise the implementor can just read the spec and see
> whether it's acceptable or not. In that case, the client must do
> either one of two things:
> 
> - Not offer the cipher suite (with the result that it takes a long
> time for such clients to get access to the latest cipher suite.) -
> Offer it and proceed with h2 if it's negotiated (potentially in
> violation of 9.2.2).
> 

The third outcome:
  - Offer it and fail h2 when client rejects the unknown (in violation
of 9.2.2 because it was safe or future AEAD and should have been
accepted).

In regards to "the implementor can just read the spec and see whether
it's acceptable or not".

Put yourself in the other shoes, imagine you were implementing RFC
2616 and the equivalent of section 9.2.2 existed there. What ciphers
would we all be forced to use today?
 Thats right, mandatory SHA1, block and stream ciphers and no way to
move to AEAD-only. Possibly even mandatory SSL/2.0 support (ouch!).
After all whats good in 1999 must be good for the few years 2616 was
projected useful for.

It's an insane idea. Just as insane as 9.2.2 without a prescribed
upgrade to better things (as opposed to mandatory downgrade to 1.1
with "bad" security).

> 
> -Ekr
> 
> [0] I think it's fairly unlikely we would deliberately standardize
> a new cipher suite that didn't work for h2 at this point, but
> that's a side issue.

So all future ciphers are and ever shall be AEAD? no.

The point of those arguing against you here is that there is a very
real possibility that sometime within the projected lifetime of h2
there will be a non-AEAD cipher developed that is safe to use with h2.
We already have a GCM block cipher "exception" and h2 lifetime has
barely even begun.

Amos

---

From: Roland Zink <[email-masked]>
Date: Wed, 24 Sep 2014 10:43:08 +0200

> As far as I can tell, either of these is fine. Do you disagree?
When h2 is upgraded to allow X (per 9.2.2X) then an old client offering 
X only for some other protocol will not work with a new h2 server as it 
will reject based on 9.2.2. So to allow X we would need h3. When you 
assume the h2 client just white lists the current set of AEAD ciphers 
then you not even can add a new AEAD cipher as the client may reject it 
for h2 even when offered in the list of supported ciphers.

Roland

---

From: Roland Zink <[email-masked]>
Date: Wed, 24 Sep 2014 10:43:49 +0200

> let others reach their own conclusions on that.
I agree that the application should do this, but the problem is about h2 
being different security than spdy or h1 within the same application. 
Especially 9.2.2 says nothing about h1. So what do you do as app 
developer if you have to implement two protocols with conflicting 
requirements? Is 9.2.2 limiting what h3 can require?
> that can offer forward secrecy.
If you accept this then you need to accept that other protocols do the 
same. TLS doesn't allow you to bind the offers to upper layer protocols.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Sep 2014 01:54:14 -0700

On Wed, Sep 24, 2014 at 1:43 AM, Roland Zink <[email-masked]> wrote:

> will reject based on 9.2.2.

Wait, how does this happen? When we introduce X we label it as acceptable
for h2. Old clients won't offer X because they won't have it and when they
do have it they should know it's acceptable for h2.

-Ekr

---

From: Roland Zink <[email-masked]>
Date: Wed, 24 Sep 2014 11:05:31 +0200

On 24.09.2014 10:54, Eric Rescorla wrote:
>
>
> On Wed, Sep 24, 2014 at 1:43 AM, Roland Zink <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     On 24.09.2014 09 <tel:24.09.2014%2009>:02, Eric Rescorla wrote:
>
>         everything is
>     When h2 is upgraded to allow X (per 9.2.2X) then an old client
>     offering X only for some other protocol will not work with a new
>     h2 server as it will reject based on 9.2.2.
>
>
Old clients may already have it in use for something different then h2, 
for example h1. It is specifically disabled for h2 in the client because 
of 9.2.2. Then you label it acceptable for h2 but this doesn't mean that 
the client code is updated.

---

From: Simone Bordet <[email-masked]>
Date: Wed, 24 Sep 2014 11:08:12 +0200

Hi,

> do have it they should know it's acceptable for h2.

Old h2 clients that are dynamically linked to a new TLS implementation
will have X but not know that is acceptable.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Sep 2014 02:11:35 -0700

On 24 September 2014 02:05, Roland Zink <[email-masked]> wrote:
> It is specifically disabled for h2 in the client because of 9.2.2. Then you
> label it acceptable for h2

Arbitrary reclassification can't happen like that.

---

From: Roland Zink <[email-masked]>
Date: Wed, 24 Sep 2014 11:14:29 +0200

> Arbitrary reclassification can't happen like that.
Exactly.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Sep 2014 02:14:15 -0700

> will have X but not know that is acceptable.

Implementations shouldn't be enabling cipher suites that they don't understand.

---

From: Simone Bordet <[email-masked]>
Date: Wed, 24 Sep 2014 11:23:22 +0200

Hi,

> Implementations shouldn't be enabling cipher suites that they don't understand.

Not sure what you mean here.

The new TLS implementation understands the cipher.
Any other non-h2 protocol will make use of it even if they don't
"understand it", because it's not their concern.
We all know h1 will work with any future TLS specification and any
future cipher.

A polyglot client that can speak multiple protocols (e.g. h1, h2)
cannot just disable ciphers globally only because one of those
protocols has special needs, also considering the client has no idea
what protocol will be chosen.

Thanks !

---

From: Roland Zink <[email-masked]>
Date: Wed, 24 Sep 2014 11:23:29 +0200

> Implementations shouldn't be enabling cipher suites that they don't understand.
You mean no cipher suite should ever be used :)

Applications may even have the cipher suite in use for other protocols 
but may not know it is allowed for h2.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Sep 2014 02:26:54 -0700

> what protocol will be chosen.

But a polyglot can ensure that it understands the implications of
enabling suite X before it does so.  For all of the protocols it
speaks.

---

From: Simone Bordet <[email-masked]>
Date: Wed, 24 Sep 2014 11:39:53 +0200

Hi,

> enabling suite X before it does so.  For all of the protocols it

Can you expand on what you mean here ?

I don't understand exactly what you mean by "software that understands
implications of enabling a cipher it does not know".
If it does not know the cipher, how can it understand any implication
of enabling it ?

Are you suggesting that every h2 client must be modified (and
recompiled if it needs to) every time a new cipher is provided by TLS,
or I totally misunderstood you (sorry if it is so) ?

Thanks !

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 24 Sep 2014 21:41:21 +1200

On 24/09/2014 9:14 p.m., Martin Thomson wrote:
> On 24 September 2014 02:08, Simone Bordet wrote:
>> Old h2 clients that are dynamically linked to a new TLS
>> implementation will have X but not know that is acceptable.
> 

In other words, h2 implementations written today must prohibit use of
TLS/1.3+ cipher suites on grounds that we will not know the ciphers
they will contain in future.

Seriously? can we not simply pick a minimum version of TLS or BCP
document as a whole and reference that?

Amos

---

From: Stuart Douglas <[email-masked]>
Date: Wed, 24 Sep 2014 19:42:34 +1000

Martin Thomson wrote:
> On 24 September 2014 02:08, Simone Bordet<[email-masked]>  wrote:

I think that this is really not the implementations concern, it should 
be up the admin and the TLS implementation. IMHO H2 implementors should 
be free to just implement the protocol, deciding on the TLS cyphers that 
should be used is up to the admins and the TLS implementation. 
Effectively banning people from using HTTP2 because they are using the 
wrong TLS implementation just seems punitive, and will hamper adoption.

I think that for the most part the people that will be implementing and 
adopting h2 are not the people using ancient insecure cyphers. I also 
think that this clause will do more to hinder the adoption of H2 than it 
will to foster the adoption of stronger cyphers.

Stuart

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Sep 2014 02:52:58 -0700

> or I totally misunderstood you (sorry if it is so) ?

The software that enables a new cipher suite has to know if it is
acceptable to h2 or not before it offers it in a handshake that might
result in h2.  The acceptability test will depend on implementations.
Some TLS stacks don't let you interrogate a cipher suite to determine
if it is acceptable, others do.  For those that permit querying suite
metadata (see ekr's post about NSS), then all that is needed is logic
like so:

  h2acceptable = !isStream && !isBlock && isFsCapable

If that is not possible for some reason (c.f., Java) then you will
need to revise the implementation to ensure that new suites don't
materialize.  The easiest way to do that is to list the suites you
know are OK and include a list of those.  That means respinning your
code to take advantage of new ciphers.

What you want to avoid is the new cipher being like this one I've
heard about: TLS_ECDHE_RSA_ROT13_CRC32

---

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

> result in h2.  The acceptability test will depend on implementations.
Don't think this is true. A client will support more than one protocol. 
Most likely h2, SPDY and HTTP/1.1. So a client may offer it and need to 
do the check after the negotiation succeeded.

Roland

---

From: Simone Bordet <[email-masked]>
Date: Wed, 24 Sep 2014 12:43:50 +0200

Hi,

>   h2acceptable = !isStream && !isBlock && isFsCapable

Ok, this will be out of date any moment a new algorithm is discovered,
and would require modify the source (and recompile).

Also, I understand it right that the logic above will apply to all
protocols spoken by the client, not only h2 ?
That is, the client can only offer ciphers that are h2 acceptable,
even if the server does not speak h2, and even if the server picks
another protocol.

A polyglot h1, h2 client correctly configured that tries to connect to
an old server won't be able to establish a connection speaking h1
because the old server won't know the new ciphers (e.g. web spiders).

Using only h1 would remove the restriction and allow connectivity to
any server, but of course it's bad for h2 adoption.

Thanks !

PS: sorry for asking so many clarifications about this, but I'm
working with the OpenJDK security team to design an API for ALPN with
the idea to support HTTP/2.
As it is now, an ALPN API is not enough to support HTTP/2, as the JDK
would also require an API to query cipher metadata, so bear with me :)

---

From: Michael Sweet <[email-masked]>
Date: Wed, 24 Sep 2014 06:22:47 -0700

Martin,

HTTP implementations that use the OS supplied TLS libraries don't have the same close integration that a browser using its own TLS library has. CUPS works with three different TLS libraries [1] (used to be four, but we dropped OpenSSL support) and all of them have vastly different interfaces and capabilities from the standpoint of cipher suite selection and classification. None of them directly allow selection based on the kind of classification that is specified in 9.2.2 and it isn't clear to me yet whether I can even specify the kind of priority ordering that is being touted as a solution for interop problems.

The reason is that these general purpose TLS libraries are themselves enforcing best practices and site policy with their defaults, and discourage developers from straying unless they are experts and know what they are doing. 9.2.2 is forcing HTTP developers to act as TLS experts...

[1] For CUPS 2.0 we support GNU TLS, SecureTransport (OSX), and SSPI (Windows).

Sent from my iPad

> On Sep 24, 2014, at 2:14 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Michael Sweet <[email-masked]>
Date: Wed, 24 Sep 2014 06:27:09 -0700

The TLS library is enabling it - the client "gets it for free" unless it goes out of its way to pick a list of cipher suites it wants to use (whitelist) or removes a list of cipher suites that is doesn't want to use (blacklist). But until HTTP/2 no HTTP client has had to specify acceptable cipher suites...

Sent from my iPad

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

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Sep 2014 06:43:37 -0700

On Wed, Sep 24, 2014 at 6:22 AM, Michael Sweet <[email-masked]> wrote:

> Martin,
>
> HTTP implementations that use the OS supplied TLS libraries don't have the
> same close integration that a browser using its own TLS library has. CUPS
> works with three different TLS libraries [1] (used to be four, but we
> dropped OpenSSL support) and all of them have vastly different interfaces
> and capabilities from the standpoint of cipher suite selection and
> classification. None of them directly allow selection based on the kind of
> classification that is specified in 9.2.2 and it isn't clear to me yet
> whether I can even specify the kind of priority ordering that is being
> touted as a solution for interop problems.
>

FWIW, you cannot provide a priority ordering for NSS.

-Ekr

> The reason is that these general purpose TLS libraries are themselves
> enforcing best practices and site policy with their defaults, and
> discourage developers from straying unless they are experts and know what
> they are doing. 9.2.2 is forcing HTTP developers to act as TLS experts...
>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 25 Sep 2014 00:49:26 +0000

Sorry Martin, I am not inclined to argue about "authority", "entitlements", "demands", or "institutional beliefs":).

I'm merely pointing out that the perception of the security of certain TLS features changes over time. If we can address TLS protocol issues at the TLS layer without modifying application protocols, it's a good thing. HTTP/2 spec requiring specific TLS cipher suites goes against this, because compatible HTTP/2 client and server need to agree on the "acceptable" TLS features, or else they will see INADEQUATE_SECURITY errors.

Cheers,

Andrei

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Tuesday, September 23, 2014 11:03 PM
To: Andrei Popov
Cc: [email-masked]
Subject: Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

Sorry about the long reply.  Too many words have been spent on this topic already, but I think that Andrei's comments go to the core of what is an important issue.

> How does this help? Basically, if the TLS layer does not filter ALPN IDs, or the HTTP layer does not filter TLS protocol versions/cipher suites/TLS extensions, then connections will sometimes fail…

This helps because it allows people who don't have the ability to alter the TLS negotiation process to determine whether things have succeeded.  It's primarily useful for clients though, where the client determines that TLS has completed, but the server chose RC4 rather than something that is actually good.

A server probably shouldn't be doing this, unless it is implemented on top of something like Java 7 and the set of suites that the client offered caused the stack to pick a bad suite.

The idea is to limit what HTTP/2 (and HTTP/1.1 in combination) requires of the TLS stack.  At this point, the following control points are required:

1. set what cipher suites are enabled
2. on the client, set the order that cipher suites are offered 3. determine what cipher suite has been negotiated

If we didn't provide INADEQUATE_SECURITY, then we would require a greater level of control, the likes of which Greg thinks we need maybe.

> 4. Update HTTP RFCs when TLS vulnerabilities are discovered; 5. Patch 
> HTTP stacks for TLS vulnerabilities; 6. Get patched HTTP stacks 
> deployed.
>

1. Events where a suite turns out to have a disastrous flaw.  This is a chemical spill situation and we will have to use disaster recovery measures, which might be drastic.  I don't see a particular burden in having to update application usages as well as the core of TLS for a disaster like that.

2. The harder problem is the slow rot of ciphers that are simply in the process of becoming obsolete.  This is what has motivated this set of requirements.  If HTTP/2 is never negotiated with RC4, that wouldn't be a bad thing.

I do want to call you out on the basic argument you are relying on here, which I think is flawed.  You seem to assume that we are not entitled to demand certain features of the TLS stack.  That the TLS stack is the one place that this sort of knowledge is enshrined.  I apologize here if I seem to have misrepresented your argument as an appeal to authority, that's not what I intend.

My interpretation of things here is that an application is able to demand a certain minimum level of protection.  More correctly, I believe that it is the responsibility of an application to make that demand.  I choose to interpret the existence of efforts like UTAas an indication that this is the institutional belief of the IETF, but will let others reach their own conclusions on that.

On the specifics of this matter, I don't think that there is any question that we are entitled to require that packets be encrypted, rather than using a suite like say TLS_RSA_WITH_NULL_SHA, which doesn't encrypt at all.  And as a practical matter, the difference between that and something as weak as TLS_RSA_WITH_DES_CBC_SHA is pretty much academic.  Maybe that distinction matters more to you, but I contend that practicality rules here.

Similarly, I believe that is well within our rights to request a suite that can offer forward secrecy.

If you accept that premise, then I think the only question is where the line is drawn.  The AEAD distinction is merely a convenient delineation point, being new enough to ensure that only relatively modern ciphers are accepted and old ones are not.  It also intentionally aligns with the choices made for TLS 1.3.

An alternative is to exhaustively enumerate the entries from the registry that we don't want, which I am also OK with.  I'm not sure that this changes the set of codecs.  And if we moved the line to permit a block cipher, the question of whether to permit the EtM variant only comes up.

I understand why you might reject this premise, I really do.  And this is a point that we may just end up disagreeing on, even if we can agree about the facts, which have at times been victim to rhetoric in this debate.

I just think that the choices we've made improve security at a holistic level, and that's what I care about most.  If we do nothing, then we've lost an opportunity, and that would be disappointing.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 25 Sep 2014 03:31:11 -0700

> and would require modify the source (and recompile).

Absolutely not true.  These properties are completely deterministic.

> even if the server does not speak h2, and even if the server picks

Not so.  A client offering different protocols can offer different
suites, it only has to understand whether each suite offered, if
selected by a server, is OK for h2.

> because the old server won't know the new ciphers (e.g. web spiders).

Yes it can.  The client can offer old cipher suites.  The old server
will just ignore the new suites.

---

From: Rob Trace <[email-masked]>
Date: Thu, 25 Sep 2014 18:32:28 +0000

Martin,

I have to disagree with some of what you are raising here.  We are essentially requiring functionality of the TLS stack interfaces to enabling filtering based on a higher layer protocol.  This is not a wire protocol specification, but a requirement for implementers to add application protocol knowledge into TLS.  It is not the same as 2618 or the upcoming UTA BCP where we specify how to use TLS as documented and implemented, we now have to change how the TLS stack filters crypto suites.

Does this mean that HTTP implementers are only allowed to use TLS platforms that provide direct HTTP/2 filtering?  This does limit HTTP developers and the ecosystem to wait for platforms to catch up, if they ever do.  If nothing else, we should consider taking this section to a separate doc or a BCP to prevent an indirect requirement for TLS implementations.

-Rob

-----Original Message-----
From: Andrei Popov [mailto:[email-masked]] 
Sent: Wednesday, September 24, 2014 5:49 PM
To: Martin Thomson
Cc: [email-masked]
Subject: RE: 9.2.2 Cipher fallback and FF<->Jetty interop problem

Cheers,

Andrei