Subject: 9.2.2, Rough Consensus, and Working Code

From: Mike Bishop <[email-masked]>
Date: Wed, 5 Nov 2014 01:42:41 +0000

By my count, the following implementations have working code or stated plans to implement the restrictions in 9.2.2:

*        Chrome/Google - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0148.html

*        Mozilla Firefox - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0143.html among others

*        Jetty - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0190.html (best effort, can't fully match)

The following have stated that they cannot or will not implement 9.2.2:

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

*        Apple - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0437.html

*        Apache - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2248.html

*        Wildfly - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2260.html

*        HAProxy - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2257.html

*        Microsoft (IE, IIS, etc.)

(If there are other implementations on either side, my apologies for missing you in my survey - please reply and voice your plans.)

Microsoft also has no current plans to implement the restrictions of 9.2.2 in client or server stacks.  We fully support this guidance as a best practice, and our default configuration will be compliant 99+% of the time.  However, we don't wish to restrict the admin's ability to change the default configuration based on local knowledge or our ability to change the defaults in the future based on new information.

Jason has described the abilities that would have to be added to TLS (http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0108.html) to support the proposed requirements, which are essentially that ALPN selection implies restrictions to the cipher suite selection (or vice versa).  There's nothing in the TLS or ALPN docs that suggests cipher suite selection has anything to do with ALPN protocol selection.  We still believe that documents specifying new TLS behavior should come from the TLS WG and be implemented in the TLS stack.

I've given RFC 7282 a read (and anyone who hasn't done so this week, please do), and I personally have to concur with Martin's assessment - we have no consensus to keep 9.2.2 in the spec as written.  However, I also believe Mark is correct that there remains a valid objection from those who want to see it included (including some outside this WG).

I believe our best path forward is to keep 9.2.2, but relax the MUSTs to SHOULDs.  I've prepared a pull request to this effect at https://github.com/http2/http2-spec/pull/641.  Either TLS implementation is free to only offer or accept cipher suites they're comfortable with, regardless of protocol, but there is no technical reason that these cipher suites are the only ones that MUST ever be used when HTTP/2 over cleartext is acceptable and HTTP/1.1 over other cipher suites is acceptable.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 5 Nov 2014 13:52:02 +1100

Mike,

I think Jetty is currently in the cannot and will not implement 9.2.2
camp.   The posting you linked to said:

Give me a robust handshake - any way you see fit, and then I will make a
best effort attempt to implement 9.2.2.

The reason for this is that without a robust handshake, then any partial
attempt to implement 9.2.2 is just going to result in handshake failure if
there are differing interpretations of the cipher restrictions.     So
given that handshakes will fail, we prefer to be able to say to frustrated
users "they are failing because the browser is insisting on offering weak
ciphers in a h2 handshake just so that they can avoid extra latency when
talking to old h1 servers".    To attempt a partial 9.2.2 implementations
will just result in involving those frustrated users in replay of all the
in depth cipher discussions that have happened here.

However, if the handshake is robust, then we are prepared to make a best
effort attempt at restricting the ciphers along the lines recommended here
(even though we do not think it is the applications protocols business),
because we know we can make a best effort attempt and not fail in the
handshake.

So your proposal of relaxing MUSTs to SHOULDs does not address my
fundamental concern of a fragile handshake.

Let's fix the handshake and then and only then can we reach a reasonable
compromise on cipher restrictions.  Without a robust handshake, Jetty will
just not go there.

cheers

On 5 November 2014 12:42, Mike Bishop <[email-masked]> wrote:

>  By my count, the following implementations have working code or stated
> plans to implement the restrictions in 9.2.2:
>
> ·        Chrome/Google -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0148.html
>
> ·        Mozilla Firefox -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0143.html
> among others
>
> ·        Jetty –
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0190.html
> (best effort, can’t fully match)
>
>
>
> ·        RedHat -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0198.html,
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0014.html
>
> ·        Apple -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0437.html
>
> ·        Apache -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2248.html
>
> ·        Wildfly -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2260.html
>
> ·        HAProxy -
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2257.html
>
> ·        Microsoft (IE, IIS, etc.)
>
>
>
> (If there are other implementations on either side, my apologies for
> missing you in my survey – please reply and voice your plans.)
>
>
>
> Microsoft also has no current plans to implement the restrictions of 9.2.2
> in client or server stacks.  We fully support this guidance as a best
> practice, and our default configuration will be compliant 99+% of the
> time.  However, we don’t wish to restrict the admin’s ability to change the
> default configuration based on local knowledge or our ability to change the
> defaults in the future based on new information.
>
>
>
> Jason has described the abilities that would have to be added to TLS (
> http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0108.html) to
> support the proposed requirements, which are essentially that ALPN
> selection implies restrictions to the cipher suite selection (or vice
> versa).  There’s nothing in the TLS or ALPN docs that suggests cipher suite
> selection has anything to do with ALPN protocol selection.  We still
> believe that documents specifying new TLS behavior should come from the TLS
> WG and be implemented in the TLS stack.
>
>
>
> I’ve given RFC 7282 a read (and anyone who hasn’t done so this week,
> please do), and I personally have to concur with Martin’s assessment – we
> have no consensus to keep 9.2.2 in the spec as written.  However, I also
> believe Mark is correct that there remains a valid objection from those who
> want to see it included (including some outside this WG).
>
>
>
> I believe our best path forward is to keep 9.2.2, but relax the MUSTs to
> SHOULDs.  I’ve prepared a pull request to this effect at
> https://github.com/http2/http2-spec/pull/641.  Either TLS implementation
> is free to only offer or accept cipher suites they’re comfortable with,
> regardless of protocol, but there is no technical reason that these cipher
> suites are the only ones that MUST ever be used when HTTP/2 over cleartext
> is acceptable and HTTP/1.1 over other cipher suites is acceptable.
>
>
>

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

---

From: Michael Sweet <[email-masked]>
Date: Tue, 04 Nov 2014 22:55:42 -0500

Greg,

This is one of the reasons why I proposed just keeping the "MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186]" requirement and dropping the rest.  That way HTTP/2 capable servers and proxies can continue to offer HTTP/1 compatible cipher suites to provide the best security and interoperability without hacks.

> On Nov 4, 2014, at 9:52 PM, Greg Wilkins <[email-masked]> wrote:
> 
> 
> Mike,
> 
> I think Jetty is currently in the cannot and will not implement 9.2.2 camp.   The posting you linked to said:
> The reason for this is that without a robust handshake, then any partial attempt to implement 9.2.2 is just going to result in handshake failure if there are differing interpretations of the cipher restrictions.     So given that handshakes will fail, we prefer to be able to say to frustrated users "they are failing because the browser is insisting on offering weak ciphers in a h2 handshake just so that they can avoid extra latency when talking to old h1 servers".    To attempt a partial 9.2.2 implementations will just result in involving those frustrated users in replay of all the in depth cipher discussions that have happened here.
> 
> However, if the handshake is robust, then we are prepared to make a best effort attempt at restricting the ciphers along the lines recommended here (even though we do not think it is the applications protocols business), because we know we can make a best effort attempt and not fail in the handshake.
> 
> So your proposal of relaxing MUSTs to SHOULDs does not address my fundamental concern of a fragile handshake.
> 
> Let's fix the handshake and then and only then can we reach a reasonable compromise on cipher restrictions.  Without a robust handshake, Jetty will just not go there.
> 
> cheers
> 
> 
> 
> 
> 
> 
> 
> 
> ·        Chrome/Google - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0148.html
> 
> ·        Mozilla Firefox - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0143.html among others
> 
> ·        Jetty – http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0190.html (best effort, can’t fully match)
> 
>  
> 
> ·        RedHat - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0198.html, http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0014.html
> 
> ·        Apple - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0437.html
> 
> ·        Apache - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2248.html
> 
> ·        Wildfly - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2260.html
> 
> ·        HAProxy - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2257.html
> 
> (If there are other implementations on either side, my apologies for missing you in my survey – please reply and voice your plans.)
> 
>  
> 
> Microsoft also has no current plans to implement the restrictions of 9.2.2 in client or server stacks.  We fully support this guidance as a best practice, and our default configuration will be compliant 99+% of the time.  However, we don’t  wish to restrict the admin’s ability to change the default configuration based on local knowledge or our ability to change the defaults in the future based on new information.
> 
>  
> 
> Jason has described the abilities that would have to be added to TLS (http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0108.html) to support the proposed requirements, which are essentially that ALPN selection implies restrictions to the cipher suite selection (or vice versa).  There’s nothing in the TLS or ALPN docs that suggests cipher suite selection has anything to do with ALPN protocol selection.  We still believe that documents specifying new TLS behavior should come from the TLS WG and be implemented in the TLS stack.
> 
>  
> 
> I’ve given RFC 7282 a read (and anyone who hasn’t done so this week, please do), and I personally have to concur with Martin’s assessment – we have no consensus to keep 9.2.2 in the spec as written.  However, I also believe Mark is correct that there remains a valid objection from those who want to see it included (including some outside this WG).
> 
>  
> 
> I believe our best path forward is to keep 9.2.2, but relax the MUSTs to SHOULDs.  I’ve prepared a pull request to this effect at https://github.com/http2/http2-spec/pull/641.  Either TLS implementation is free to only offer or accept cipher suites they’re comfortable with, regardless of protocol, but there is no technical reason that these cipher suites are the only ones that MUST ever be used when HTTP/2 over cleartext is acceptable and HTTP/1.1 over other cipher suites is acceptable.
> 
>  
> 
> 
> 
> 
> -- 
> Greg Wilkins <[email-masked]>  @  Webtide - an Intalio subsidiary

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 09:32:20 +1100

Hey Mike,

One question - why did you change it so that only the client can generate INADEQUATE_SECURITY?

Also, it seems like this is orthogonal to Martin's proposal:
  https://github.com/http2/http2-spec/pull/615

What do people (including you, Mike) think about combining them (perhaps without the change above, unless we can motivate it)?

> On 5 Nov 2014, at 12:42 pm, Mike Bishop <[email-masked]> wrote:
> 
> I believe our best path forward is to keep 9.2.2, but relax the MUSTs to SHOULDs.  I’ve prepared a pull request to this effect athttps://github.com/http2/http2-spec/pull/641.  Either TLS implementation is free to only offer or accept cipher suites they’re comfortable with, regardless of protocol, but there is no technical reason that these cipher suites are the only ones that MUST ever be used when HTTP/2 over cleartext is acceptable and HTTP/1.1 over other cipher suites is acceptable.

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

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 6 Nov 2014 10:10:07 +1100

On 6 November 2014 09:32, Mark Nottingham <[email-masked]> wrote:
> What do people (including you, Mike) think about combining them (perhaps
without the change above, unless we can motivate it)?

I'm generally +1 on the changes in /pull/615, with the caveat that it still
has a fragile handshake.  I like that it adds the text:

 + A client that generates or receives an
<x:ref>INADEQUATE_SECURITY</x:ref> connection error
 + MAY choose to disable HTTP/2 and attempt to reconnect with the same peer
using an
 + alternative protocol, such as HTTP/1.1. Note that this entails a risk of
downgrade attack
 + if the client does not properly validate that the TLS handshake has been
completed; this
 + is especially likely if clients support <xref
target="TLS-FALSE-START">TLS false
 + start</xref>.

that provides a fallback mechanism for clients that wish to talk to old
servers with weak ciphers.   So with that text, we no longer need the
current fallback mechanism that is causing the fragile handshake.   We
don't need two fallback mechanisms, so let's remove:

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

Then we don't have a fragile handshake and we better follow the feedback
from the Area Director and other IETF leadership, that we should not
support weak ciphers.    This fragile handshake has always been the
sticking point for me.  With a robust handshake, Jetty can and will make
best effort attempt to implement recommendations without risk of handshake
failures.

With regards to /pull/641 It has similar retry text to 615.

 + Due to implementation
 + limitations, it might not be possible to fail TLS negotiation. A client
MAY
 + immediately terminate an HTTP/2 connection that does not meet its TLS
requirements
 + with a <xref target="ConnectionErrorHandler">connection error</xref> of
type
 + <x:ref>INADEQUATE_SECURITY</x:ref> before retrying with a different TLS
configuration.

I think 615's version is probably a little bit better, although 641 does
suggest that a retry can be done on a TLS failure as well as an
INADEQUATE_SECURITY.   But either approach is fine with me, or a merge of
the two.

I'm also fine with the detuning of MUST to SHOULD, as I think that will
represent how this is implemented anyway.  Deployers will make best efforts
to comply, but there will always be exceptions.

cheers

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 10:16:05 +1100

Mike,

Digging into this a bit --

We have 24 reasonably current implementations listed, many of them demonstrating interop.

> ·        RedHat - http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0198.html, http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0014.html

RedHat does not have an implementation listed.

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

Apple is not currently implementing, as far as we know, so this is a statement of Michael's opinion, not implementation support. Additionally, Michael AFAIK does *not* represent Safari or Apple's HTTP stack; he's working on printing protocols (some of which use HTTP). Michael, please correct me if this is incorrect.

> ·        Apache - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2248.html

Apache httpd is not currently listed as implementing, so this is a statement of Roy's opinion, not implementation support.

> ·        Wildfly - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2260.html

Wildfly does not have an implementation listed. I believe Stuart also works on JBoss, which is also not currently on the implementation list.

> ·        HAProxy - http://lists.w3.org/Archives/Public/ietf-http-wg/2014JulSep/2257.html

HAProxy does not have an implementation listed.

> ·        Microsoft (IE, IIS, etc.)

... Microsoft DOES have an implementation listed.

So claims of "working code" seem to be premature here. We don't determine everything by running code here, but when we use it to motivate an argument, let's try to get it right. Some of these folks may have implementations planned or in the works, but they haven't yet brought running code to the party. 

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 10:25:38 +1100

Thinking about this a bit more --

> Microsoft also has no current plans to implement the restrictions of 9.2.2 in client or server stacks.  We fully support this guidance as a best practice, and our default configuration will be comp…

So, I interpret that as "Microsoft will ship a product that is *able* to be conformant, and will by default and also very often actually be conformant, but it will be possible for an admin to configure it in a way that is non-conformant."

If that's roughly true, I personally think that's OK, and not even unusual or even remarkable for products that implement IETF protocols. Thoughts?

> Jason has described the abilities that would have to be added to TLS (http://lists.w3.org/Archives/Public/ietf-http-wg/2014OctDec/0108.html) to support the proposed requirements, which are essentia…

That's one possible implementation technique to enable conformance. Another is to use cipher suite preferences, as many are now doing. How is that inadequate?

> I believe our best path forward is to keep 9.2.2, but relax the MUSTs to SHOULDs.  I’ve prepared a pull request to this effect athttps://github.com/http2/http2-spec/pull/641.  Either TLS implementa…

I'm concerned that relaxing those requirements will actually make it *more* likely that we'll see interop problems; as discussed, implementations that conform to the proposed text ought not encounter any interop issues, but if we make those SHOULDs, we're creating Greg's "brittle handshake."

Cheers,

---

From: Mike Bishop <[email-masked]>
Date: Wed, 5 Nov 2014 23:39:09 +0000

You keep sending a new e-mail, and I keep rebasing my replies....  :-)  Your interpretation is mostly correct, except that we don't plan to make the investment to *enforce* compliance by the other party, which the spec currently requires.  We disagree with requiring enforcement, and would remove that MUST.  But if there's no required enforcement, then the others aren't really MUSTs, either.  All of the edits in my pull request flow from that single difference.

Why only clients send INADEQUATE_SECURITY?  The client knows what it offered and what that resulted in on the server -- if it doesn't like the outcome, it can notify the server that it's closing the connection and try again with a different offer.  The server, on the other hand, doesn't have a path forward if it sends INADEQUATE_SECURITY.  If it rejects the client's security settings, the client can't know for sure what configuration the server would accept -- that seems the very definition of Greg's "fragile handshake."  At that point, you're not negotiating, you're playing Twenty Questions, guessing at the overlap of the TLS-layer config and the HTTP-layer config.

Regardless of protocol selection, the server should only ever accept a cipher suite it's willing to use, and should pick the most preferred cipher suite the client offers.  (And by the HTTP/2 spec, we know that it will support at least one hopefully-still-good cipher if it's offering HTTP/2.)  We don't need HTTP-layer logic to do that -- that's how the TLS stack works today.

I think our underlying differences in this discussion are:
    - Should an HTTP/2-capable server *refuse* to speak HTTP/2 with an HTTP/2-capable client because the client's best cipher suite is too low on its own preference list, but still acceptable per its TLS configuration?
    - Should there be an HTTPbis-mandated TLS configuration that either subsets or constrains local TLS configuration?

We believe not, on both counts.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Wednesday, November 5, 2014 3:26 PM
To: Mike Bishop
Cc: HTTP Working Group
Subject: Re: 9.2.2, Rough Consensus, and Working Code

Cheers,

---

From: Mike Bishop <[email-masked]>
Date: Wed, 5 Nov 2014 23:47:36 +0000

That's true, but for the most part these are the people who *will* be implementing what we produce once it's finalized.  If they say that they will not be implementing something that's in the spec when they eventually get around to their implementation, I think their feedback is still worth bearing in mind.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Wednesday, November 5, 2014 3:16 PM
To: Mike Bishop
Cc: HTTP Working Group
Subject: Re: 9.2.2, Rough Consensus, and Working Code

Mike,

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 11:02:23 +1100

> On 6 Nov 2014, at 10:39 am, Mike Bishop <[email-masked]> wrote:
> 

I kind of disagree with that last point; if the administrator is choosing cipher suites but the implementation decides when to send INADEQUATE_SECURITY, there are two different points of control, and it may make sense to diverge in requirement levels.

So, maybe the path forward would be to leave the cipher suite requirements at MUST -- putting the responsibility for conforming on the administrator in some deployments -- but reduce the requirement to generate INADEQUATE_SECURITY to a SHOULD, thereby letting an implementation that doesn't have the ability (or desire) to enforce off the hook.

Need to think through the implications of that, but WDYT?

> Why only clients send INADEQUATE_SECURITY?  The client knows what it offered and what that resulted in on the server -- if it doesn't like the outcome, it can notify the server that it's closing th…

I interpret the server generating INADEQUATE_SECURITY as it saying "sorry, we can't talk, we're done." In some (hopefully rare) cases, that's entirely appropriate.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Nov 2014 16:05:49 -0800

On 5 November 2014 15:39, Mike Bishop <[email-masked]> wrote:
> if there's no required enforcement, then the others aren't really MUSTs, either.

Only if you like to play Russian Roulette.  If the others aren't
MUSTs, then when you don't comply you risk getting shut down.  That's
interoperability failure of a sort, is it not?

> If it rejects the client's security settings, the client can't know for sure what configuration the server would accept

I don't think that this is right.  The reasons for sending
INADEQUATE_SECURITY are precise, so it has to be one of those things.
You aren't allowed to send INADEQUATE_SECURITY for other reasons (that
is a clarification that I'm prepared to add to #615).  Can you
describe a scenario where the server would send this message and the
client would be unable to determine what was wrong?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 5 Nov 2014 16:07:26 -0800

> So, maybe the path forward would be to leave the cipher suite requirements at MUST -- putting the responsibility for conforming on the administrator in some deployments -- but reduce the requiremen…

I think that would work.  It would hide errors, which I think we've
tried not to do generally, but it's a practical escape valve for some
cases.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 5 Nov 2014 16:37:32 -0800

More to the point, they do implement HTTP, and the chartered goal of
this working group is to produce a protocol that they will be willing
to adopt as a replacement for HTTP/1.  If you want to change the name
of the protocol to TLS+, feel free to do so and ignore the existing
implementations.

I know Apache httpd won't be implementing 9.2.2 because the HTTP-aware
code doesn't even get involved in connection activity until after the
first HTTP message is received.  Furthermore, there is no way of
knowing if an external device is securing the connection.
When we do have an implementation of HTTP/2, it won't be limited to
TLS for the same reason HTTP/1 isn't limited to TCP.

I am sorry that the ADs don't seem to understand the concept.
If they have a problem with the adequacy of TLS, they are
fully capable of publishing TLS 1.3 as a minimum set of changes
and let the session-level protocol negotiate correctly.

Right now, there are zero implementations of server-side 9.2.2 and
no expressions of interest.  So, unless this is rough consensus and
running ADs, the IETF decision should be to delete 9.2.2, or at least
delete the requirements it makes on servers.  This does not, in any way,
prevent user agents from refusing to make requests on what they
consider to be an inadequately secured connection.

....Roy

---

From: Nicholas Hurley <[email-masked]>
Date: Wed, 05 Nov 2014 16:45:34 -0800

On Wed, Nov 5, 2014, at 16:37, Roy T. Fielding wrote:
> no expressions of interest.

node-http2 (server-side, as well as client-side) *will* be implementing
9.2.2 as soon as the APIs exist in node to facilitate that (which should
occur with the release of node 0.12).
-- 
Peace,
  -Nick

---

From: "Martin Nilsson" <[email-masked]>
Date: Thu, 06 Nov 2014 02:09:34 +0100

On Wed, 05 Nov 2014 04:55:42 +0100, Michael Sweet <[email-masked]> wrote:

> Greg,
>
> This is one of the reasons why I proposed just keeping the "MUST support  
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with P256 [FIPS186]"  
> requirement and dropping the rest.  That way HTTP/2 capable servers and  
> proxies can continue to offer HTTP/1 compatible cipher suites to provide  
> the best security and interoperability without hacks.
>

This, together with some text defining DH parameter size, is good because  
it allows everyone to do the right thing. It is bad because it doesn't  
force everyone to do the right thing. However, the current 9.2.2 text  
doesn't force the implementations to do the right thing from protocol  
design, but by coercion. If the client sends all possible ciphers and the  
server selects a non-TLS1.3 cipher, then there is nothing technically that  
stops the client from accepting that. Rules without enforcement are  
recommendations.

So we could move from the current 9.2.2 text saying

                                     MUST  SHOULD  MAY
Client sends ECDHE-AES-GCM          X
Server selects TLS 1.3 compatible   X
Client verifies server selection    X

to
                                     MUST  SHOULD  MAY
Client sends ECDHE-AES-GCM          X
Server selects TLS 1.3 compatible   X
Client verifies server selection          X

and get something stronger than Michaels proposal that maybe is palatable  
to those without API flexibility to the TLS stack they integrate with.

/Martin Nilsson

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

---

From: "Jain, Shakesh" <[email-masked]>
Date: Wed, 5 Nov 2014 19:15:45 -0600

>occur with the release of node 0.12).

Akamai proxy supports 9.2.2 as well.

Shakesh

---

From: "Martin Nilsson" <[email-masked]>
Date: Thu, 06 Nov 2014 02:17:24 +0100

On Thu, 06 Nov 2014 01:02:23 +0100, Mark Nottingham <[email-masked]> wrote:

>
> So, maybe the path forward would be to leave the cipher suite  
> requirements at MUST -- putting the responsibility for conforming on the  
> administrator in some deployments -- but reduce the requirement to  
> generate INADEQUATE_SECURITY to a SHOULD, thereby letting an  
> implementation that doesn't have the ability (or desire) to enforce off  
> the hook.
>

I'll echo Mikes rebasing comment. In my other email I agree with you...

/Martin Nilsson

---

From: Michael Sweet <[email-masked]>
Date: Wed, 05 Nov 2014 21:46:36 -0500

Mark,

> On Nov 5, 2014, at 6:16 PM, Mark Nottingham <[email-masked]> wrote:
> ...

While my primary focus *is* on IPP (really the only print protocol being "worked on" and deployed in close to 500 million printers over the last 4 years), I am one of the few people at Apple that represents our interests in the IETF and other standards bodies so I naturally work internally with other groups inside Apple to make sure I fairly represent all of Apple's interests - in this case printing, web client, and web/content serving.

As you may have noticed, Apple is generally pretty secretive about the work it does leading up to a product release.  So the lack of an official statement from the Safari or WebKit teams is *not* informative - until a release is public, they generally cannot say anything about what Apple may or may not implement.

That said, I can (as an official representative of Apple) make statements about what is currently released or what is available as open source software.  And I believe I have been very clear on our (Apple's) position and dislike for the current 9.2.2 text:

1. Apple's SecureTransport API already supports the required cipher suite identified in the current draft's section 9.2.2.  So we are OK there.

2. Apple's SecureTransport API does not support a way to filter cipher suites based on capabilities (i.e. AEAD vs. CBC, etc.)  It does support (barring a current bug) specification of which cipher suites are enabled, and it is possible to implement a crude whitelist/blacklist approach to allow the widest possible set of cipher suites to be negotiated.  We could live with such a hack, but doing so interferes with HTTP/1 compatibility.

3. Since ALPN provides no way to restrict cipher suites based on negotiated protocol, a Client that tries to opportunistically use HTTP/2 will fail when connecting to many existing HTTP/1 servers.  This will force an additional connection attempt in a HTTP/1-only mode, impacting performance, power usage, etc. which is a deal-breaker for Apple.

These issues exist independent of whether I write a web browser, web/content server, or printer software for Apple - they are fundamental limitations of the APIs and protocol (TLS) we both must use.  And my current prototype implementation (running code) of the HTTP/2 drafts is unable to support the restrictions of 9.2.2 - not only can I not restrict the allowed cipher suites right now (thanks to a SecureTransport bug), but even if that API worked I would still run into problems when communicating with non-HTTP/2 implementations that don't implement the newer cipher suites (pretty common in the printing world, just like the web server world...)

My (Apple's) proposed alternative is to simply change the MUST and MUST NOT to SHOULD and SHOULD NOT: these are security best practices, not requirements to support interoperability.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 5 Nov 2014 21:57:43 -0500

On Wed, Nov 5, 2014 at 6:39 PM, Mike Bishop <[email-masked]>
wrote:

> Your interpretation is mostly correct, except that we don't plan to make
> the investment to *enforce* compliance by the other party, which the spec
> currently requires.

I hear ya. A requirement that says you must do something in reaction to
receiving something the other side MUST NOT send (but did anyhow) isn't
really the most important thing in the world. Even if you're non compliant
on that front there is no way for a compliant implementation to notice so
there is no threat to interop between conforming implementations.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 5 Nov 2014 22:10:44 -0500

On Wed, Nov 5, 2014 at 7:02 PM, Mark Nottingham <[email-masked]> wrote:

> So, maybe the path forward would be to leave the cipher suite requirements
> at MUST -- putting the responsibility for conforming on the administrator
> in some deployments -- but reduce the requirement to generate
> INADEQUATE_SECURITY to a SHOULD, thereby letting an implementation that
> doesn't have the ability (or desire) to enforce off the hook.
>
I'm assuming the Y in WDYT opened that question up to the room :)

I think this is reasonable on balance. As Martin has already noted we've
tended to favor harder error handling requirements but if the
practicalities of this protocol requirement mean it will be fulfilled by
agreement outside of the h2 implementation (e.g. via config of a
coordinated partner application)  then it makes sense to be more flexible
here wrt generating INADEQUATE_SECURITY.

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 14:28:00 +1100

Dare I say MAY?

> On 6 Nov 2014, at 2:10 pm, Patrick McManus <[email-masked]> wrote:
> 
> 
> I think this is reasonable on balance. As Martin has already noted we've tended to favor harder error handling requirements but if the practicalities of this protocol requirement mean it will be fulfilled by agreement outside of the h2 implementation (e.g. via config of a coordinated partner application)  then it makes sense to be more flexible here wrt generating INADEQUATE_SECURITY.

---

From: Jason Greene <[email-masked]>
Date: Wed, 5 Nov 2014 23:16:24 -0600

MAY makes more sense. You want servers to validate ciphers, but without the proper TLS hooks, this needs to be limited to rejecting known bad ciphers. As previously discussed, when the client white lists, and the server black lists, you end up with the exact same security as the the current draft, but instead with a robust handshake. This is the thinking behind #639, which is very similar to what you propose.

> On Nov 5, 2014, at 9:28 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Dare I say MAY?
> 

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

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 6 Nov 2014 16:15:55 +1100

> Dare I say MAY?

You MAY say MAY,  but increased flexibility with the interpretation of
9.2.2 requirements just makes it all the more important to have a robust
handshake.

Let's consider the original interoperability problem that raised this issue
and consider how MAY would help or hinder.

I ran Jetty's http2 server on Java-7, which has no ciphers that are
satisfactory with regards to 9.2.2.    FF offered a connection with a
cipher set that included both 9.2.2 acceptable and non acceptable
ciphers.    Jetty's http2 implementation did not implement 9.2.2 and choose
to accept whatever cipher was negotiated based on what the client offered
and how the JVM had been configured (as a recently released and still
supported JVM, it had no known weak ciphers), together with h2.       FF
then applied it's 9.2.2 implementation and rejected the connection.
Thus we failed to communicate even though both client and server spoke h1
and h2, and both were configured with recently updated black/white lists of
acceptable ciphers.    All we did was turn on h2 support and this caused a
server from being able to communicate with a client.  Turning off h2
support in either the client or the server allowed connections to succeed.

In the current draft, the fault for this interoperability failure was with
Jetty, as we did not implement 9.2.2.        I looked into implementing
9.2.2 and discovered that not only are unable to affect cipher negotiation,
but that we have no API with which to query cipher properties.     The only
implementations of 9.2.2 that are available to use are basically regex
and/or name white/black lists, so that this would leave our interpretation
of 9.2.2 subject to configuration and future changes to cipher naming
conventions.  If we are ever configured with a different interpretation of
9.2.2 than our clients, then connections can fail even if there are
mutually acceptable ciphers/protocols.    Thus was born the fragile
handshake issue.

If we replace MUST with MAY, this make the handshake fragility a much
greater interoperability problem.   If the server MAY respond with
INADEQUATE_SECURITY, then it also MAY NOT.   Jetty's deferral of cipher
selection to the TLS layer will now be spec compliant and the failure to
connect even though there were shared ciphers and protocols because a real
problem today rather than a possible problem when faces with hypothetical
future cipher names.  This makes the handshake broken rather than fragile.

I know I sound like a scratched record - but we MUST have a robust
handshake that does not rely on how we "think" ciphers will evolve.

regards

---

From: Jason Greene <[email-masked]>
Date: Wed, 5 Nov 2014 23:26:41 -0600

> On Nov 5, 2014, at 11:15 PM, Greg Wilkins <[email-masked]> wrote:
> 
> If we replace MUST with MAY, this make the handshake fragility a much greater interoperability problem.   If the server MAY respond with INADEQUATE_SECURITY, then it also MAY NOT.   Jetty's deferral of cipher selection to the TLS layer will now be spec compliant and the failure to connect even though there were shared ciphers and protocols because a real problem today rather than a possible problem when faces with hypothetical future cipher names.  This makes the handshake broken rather than fragile.
> 
> I know I sound like a scratched record - but we MUST have a robust handshake that does not rely on how we "think" ciphers will evolve.  

Hi Greg, can you take a look at the small proposal I sent a few days ago. I think its closer to what you are looking for:
https://github.com/http2/http2-spec/pull/639/files

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 16:40:58 +1100

I'd really like to hear what people think about this; it might need some wordsmithing around "unknown", etc. but it's a fairly small change...

> On 6 Nov 2014, at 4:26 pm, Jason Greene <[email-masked]> wrote:
> 
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 16:40:24 +1100

> On 6 Nov 2014, at 4:15 pm, Greg Wilkins <[email-masked]> wrote:
> 
> 
> You MAY say MAY,  but increased flexibility with the interpretation of 9.2.2 requirements just makes it all the more important to have a robust handshake.
> 
> Let's consider the original interoperability problem that raised this issue and consider how MAY would help or hinder.
> 
> I ran Jetty's http2 server on Java-7, which has no ciphers that are satisfactory with regards to 9.2.2.

Then it's not conformant to 9.2.2. This is not an interop problem -- it's a failure to conform.

As I explained, the only way we can consider this an interop issue is if it affects the ecosystem in such a way that it seriously retards deployment of the protocol (i.e., it puts it at risk). One -- or a handful -- of implementations that can't conform with their current APIs is NOT a technical issue.

Yes, I realise that's... not great... for some, but I think that's where we're at. However, I don't think it's that dim -- see below.

> FF offered a connection with a cipher set that included both 9.2.2 acceptable and non acceptable ciphers.    Jetty's http2 implementation did not implement 9.2.2 and choose to accept whatever cipher was negotiated based on what the client offered and how the JVM had been configured (as a recently released and still supported JVM, it had no known weak ciphers), together with h2.       FF then applied it's 9.2.2 implementation and rejected the connection.      Thus we failed to communicate even though both client and server spoke h1 and h2, and both were configured with recently updated black/white lists of acceptable ciphers.    All we did was turn on h2 support and this caused a server from being able to communicate with a client.  Turning off h2 support in either the client or the server allowed connections to succeed.
> 
> In the current draft, the fault for this interoperability failure was with Jetty, as we did not implement 9.2.2.        I looked into implementing 9.2.2 and discovered that not only are unable to affect cipher negotiation, but that we have no API with which to query cipher properties.     The only implementations of 9.2.2 that are available to use are basically regex and/or name white/black lists, so that this would leave our interpretation of 9.2.2 subject to configuration and future changes to cipher naming conventions.  If we are ever configured with a different interpretation of 9.2.2 than our clients, then connections can fail even if there are mutually acceptable ciphers/protocols.    Thus was born the fragile handshake issue.

Most servers have exposed the black/white lists as configuration metadata, and presumably will give guidance / good defaults to the admin to assure that it will be 9.2.2-conformant. Why is this not adequate, until you have appropriate APIs in place?

> If we replace MUST with MAY, this make the handshake fragility a much greater interoperability problem.   If the server MAY respond with INADEQUATE_SECURITY, then it also MAY NOT.   Jetty's deferra…

Well, it makes it a conformance issue at runtime, one that will be very evident once the admin points Firefox or Chrome at the server. AIUI the idea is that they'll self-correct (quickly).

> I know I sound like a scratched record - but we MUST have a robust handshake that does not rely on how we "think" ciphers will evolve.  

I know, I think most people feel like that. All I can do is continue to try to move the discussion forward. At some point, I'll have to call consensus, and I'm hoping we can find more common ground than we have now before doing so.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 6 Nov 2014 18:13:33 +1100

> On 6 Nov 2014, at 6:11 pm, Jason Greene <[email-masked]> wrote:
> 
> Undertow has our first implementation. It implements draft-14, although is fairly new code. I added it to the wiki. Not sure if there is anything special we should be doing outside of that.

Great! If you can expose a public endpoint and leave its details on a wiki page (linked from your entry, like others), that would be wonderful. Instructions for setting up a test server / client are also good, of course.

Cheers,

---

From: Jason Greene <[email-masked]>
Date: Thu, 6 Nov 2014 01:11:32 -0600

> On Nov 5, 2014, at 5:16 PM, Mark Nottingham <[email-masked]> wrote:
> 
...

---

From: Jason Greene <[email-masked]>
Date: Thu, 6 Nov 2014 01:29:21 -0600

> On Nov 6, 2014, at 1:13 AM, Mark Nottingham <[email-masked]> wrote:
> 
> 

Ok we will get that setup. Thanks for the info, sorry you probably had to repeat.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 6 Nov 2014 18:47:27 +1100

On 6 November 2014 16:40, Mark Nottingham <[email-masked]> wrote:

> satisfactory with regards to 9.2.2.
>

That is exactly what I said.  But if you change to a MAY rather than a MUST
it is a broken rather than fragile handshake.
Even as a MUST implementations of 9.2.2 will be sufficiently mutable (see
your point about configurable white/black lists below), that it is likely
that differences will be experience and interop problems will result.

Most servers have exposed the black/white lists as configuration metadata,
> and presumably will give guidance / good defaults to the admin to assure
> that it will be 9.2.2-conformant. Why is this not adequate, until you have
> appropriate APIs in place?
>

Again exactly my point.  Not only will servers use configurable black/white
lists, but so will many non browser clients.

Enter the proverbial new XYZ cipher and we now have our interop problem.
Servers will start to see XYZ ciphers offered, but because of the fragile
handshake they have no idea if XYZ is being offered for h2 or not.

So if a server then adds XYZ to it's h2 white list, it will not be able to
talk to those clients that have allowed XYZ to be added to their TLS
ciphers, but have not yet added it to their h2 white list.    If the server
does not add it to their white list, then they may not be able to use an
important new cipher that is needed to avert some security threat.

We all appear to accept that TLS and h2 cipher acceptability will be
configurable via white/black lists, so at best 9.2.2 can only be considered
a recommendation for the default values of the h2 black list.
Fundamentally it is configuration and we cannot put servers in the position
where they have the choice between talking to new strong ciphers vs losing
connection with clients that have not yet h2 white listed the new strong
cipher.

Well, it makes it a conformance issue at runtime, one that will be very
> evident once the admin points Firefox or Chrome at the server. AIUI the
> idea is that they'll self-correct (quickly).

I think this indicates you are missing the fundamental aspect of my
concern.  Sure an admin can configure the server correctly to talk to 1
particular clients configuration.  But they cannot configure it to connect
to all legal clients configurations at the same time.    The client
population is going to lag and you are asking servers to disconnect from
populations during the process of introducing new ciphers.

This is a likely issue if 9.2.2 is a MUST.  This is a broken spec if 9.2.2
is a MAY.

cheers

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 6 Nov 2014 18:52:43 +1100

On 6 November 2014 16:26, Jason Greene <[email-masked]> wrote:
>
>
> Hi Greg, can you take a look at the small proposal I sent a few days ago.
> https://github.com/http2/http2-spec/pull/639/files

Jason,

your proposal says:

+ latency imposed by using a separate connection for fallback. Prohibited
cipher suites
+ MUST be advertised at a lower preference than permitted cipher suites.

I don't think ordering helps as there may be no ciphers in intersection of
client/server h2 acceptable cipher sets (as was the case when I ran jetty
on java 7).    Without a robust handshake, it is impossible for a server to
know at what point in the list of offered ciphers the weak fallback ciphers
begin.   Many servers will never even see the list and will just see the
negotiated cipher.

+ </t>
+ <t>
+ Servers MAY allow unknown ciphers that are negotiated by a TLS 1.2
implementation.
+ This prevents potential interoperability issues involving future ciphers
supported
+ by the underlying TLS 1.2 implementation, but are not yet understood by
the server.
+ Due to the restrictions on clients above, prohibited cipher suites are
still
+ prevented from use with HTTP/2.

If the server allows an unknown cipher for h2, and the client rejects it
with inadequate security, then the connection will have failed - EVEN if
there are acceptable ciphers if h1 was chosen.

Also note that a server might not get to choose h1 over h2 as the ALPN may
be offloaded with TLS.

So the fundamental problem is that the current handshake even with your
amendments allows a client to offer a cipher which it later rejects with
inadequate security.    That is a broken handshake.

cheers

---

From: Michael Sweet <[email-masked]>
Date: Thu, 06 Nov 2014 06:11:52 -0500

There are two problems with it:

1. Many (GNU TLS, OpenSSL, MS SPI, and Apple SecureTransport for sure) have no API to control the order of cipher suites

2. It still forbids the use of non-conforming ciphers which can only be enforced after a successful TLS negotiation if an endpoint wants to support both HTTP/1 and HTTP/2.

Sent from my iPad

> On Nov 6, 2014, at 12:40 AM, Mark Nottingham <[email-masked]> wrote:
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 6 Nov 2014 14:24:25 +0200

> 9.2.2 requirements just makes it all the more important to have a robust

Thinking about it, I see three ways to get robust handshake with cipher
restrictions:

1) Without TLS stack support on either side:

- First handshake: Only known acceptable ciphers, TLS 1.2+, (h1+)h2.
- INADEQUATE_SECURITY is only sent for known unacceptable ciphers[1].
- Second handshake (if dual-version): All ciphers, h1.

- Implementable today in major TLS stacks.
- Sending only known acceptable ciphers in first handshake "punishes"
  bad servers (only bad crypto, not lack of h2 support) with extra
  latency.

2) Without TLS stack support on either side (dual-version): 

- First handshake: All ciphers, h1+h2.
- INADEQUATE_SECURITY is only sent for known unacceptable ciphers[1].
- Second handshake: All ciphers, h1.

- Implementable today in major TLS stacks.
- Not possible for h2-only clients (those can do 1)).
- Here there is possiblity that server picked h2 and some not-really-
  acceptable cipher (client may or may not reject).
- Second handshake is done even on INADEQUATE_SECURITY by either side
  (not doing this leads to hard interop failures[2])

3) With server TLS stack support:

- Client handshake, all ciphers, (h1+)h2.
- INADEQUATE_SECURITY is sent for known unacceptable ciphers.
- Servers only select h2 with acceptable ciphers[3][4].

- (Most?) major TLS stacks need additions.
- Server can't have unknown ciphers, because if client knows one is
  unacceptable, server can pick it with h2 and then client sends
  INADEQUATE_SECURITY. Boom.

[1] This is NOT the same as not known aceptable, since there can
be unknown ciphers.

[2] Solution: Disable h2 (client or serverside).

[3] This is exact (MUST query TLS stack for cipher properties).

[4] Server is capable of varying ciphersuite selections based on
ALPN.

-Ilari

---

From: Patrick McManus <[email-masked]>
Date: Thu, 6 Nov 2014 10:04:25 -0500

> Dare I say MAY?

in this particular case I think {SHOULD NOT, MAY, SHOULD} are largely the
same when implementing a conforming peer - its something to prepare for but
that cannot be relied on. SHOULD is better advice, but I don't think it
really will make a difference in practice so I would feel the same about
both SHOULD and MAY.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 6 Nov 2014 17:44:14 +0200

> On Nov 6, 2014, at 5:04 PM, Patrick McManus <[email-masked]> wrote:
> 
> 
> On Wed, Nov 5, 2014 at 10:28 PM, Mark Nottingham <[email-masked] <mailto:[email-masked]>> wrote:
> Dare I say MAY?
> 
> in this particular case I think {SHOULD NOT, MAY, SHOULD} are largely the same when implementing a conforming peer - its something to prepare for but that cannot be relied on. SHOULD is better advice, but I don't think it really will make a difference in practice so I would feel the same about both SHOULD and MAY.

What I generally hear from ADs is that SHOULD and SHOULD NOT have to come with and explanation of when you’re allowed to not follow them, for example, “SHOULD support at least 100 concurrent streams unless this is a constrained environment.”  MAY can be used without guidance. 

“SHOULD unless you use libraries with insufficient hooks” sounds like an implementation issue, a close relative of “SHOULD unless you really really don’t want to”. I think Mark should dare to say MAY.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 6 Nov 2014 19:12:52 +0200

Hi, Roy

> On Nov 6, 2014, at 2:37 AM, Roy T. Fielding <[email-masked]> wrote:
> 

Does this mean that Apache won’t be enforcing the TLS requirements at all? IOW, if the configuration string for OpenSSL allows TLS_RSA_EXPORT_WITH_RC4_40_MD5 negotiated over SSLv3, httpd will be fine with this cipher and version?

I’m not criticizing, just asking.

Yoav

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 6 Nov 2014 10:27:19 -0800

> Does this mean that Apache won’t be enforcing the TLS requirements at all? IOW, if the configuration string for OpenSSL allows TLS_RSA_EXPORT_WITH_RC4_40_MD5 negotiated over SSLv3, httpd will be fi…

The httpd interface to TLS tries to encompass many different libraries.
To the extent that such algorithm choices are available to the server,
the configuration files for TLS allow the administrator to select them.
It doesn't have anything to do with the HTTP filters within httpd (the
code that actually implements HTTP standards).

We occasionally disable choices within the TLS interface that have known
security vulnerabilities, but we generally prefer secure defaults and
shoot-your-own-foot flexibility (due to the universe of legacy platforms
that httpd wants to run within that don't always have the latest features).
However, I can't really say what the SSL interface will likely support,
since it is orthogonal to HTTP and depends on exactly why TLS has
deprecated a given feature.  If you want to know what Apache httpd will
support for HTTP/2 communication, look at what it supports for HTTP/1.

Generally speaking, if people think something is insecure of HTTP/2,
it would be foolish to continue using that for HTTP/1.  However, we
still need to allow such options to be configured because one of the
roles of an HTTP server is to provide access to software updates.
Hence, in some circumstances, backwards compatibility does override
specific security concerns because the alternative is less secure
in general.

These choices are made prior to any connection, regardless of the
protocol used on top of TLS.  Terminating the connection just because
the client successfully negotiated a variation of TLS that isn't good
enough for 9.2.2 is a stupid idea because it places me in the position
of overriding the administrator's deliberate choice to configure some
other (non-default) choices for TLS.  I cannot possibly guess why they
made those choices, since it depends on the environment in which they
are operating and the purpose of the content served.  In contrast,
I know all too well that 9.2.2 is nothing more than a punt by browser
vendors and a political statement by folks who have no operational
responsibility.

....Roy

---

From: Jason Greene <[email-masked]>
Date: Thu, 6 Nov 2014 12:37:04 -0600

> On Nov 6, 2014, at 5:11 AM, Michael Sweet <[email-masked]> wrote:
> 

I thought the priority strings would be sufficient, but testing at least GNUTLS, shows the order provision in my proposal, as written being unenforceable on this implementation. Unsurprisingly, the default order is all wrong[1].

You can get it close, but not completely accurate because it appears to sort key exchange over mac. As an example a priority string like:

'NONE:+AEAD:+AES-256-GCM:+AES-128-GCM:+SHA256:+AES-256-CBC:+AES-128-CBC:+VERS-TLS1.2:+ECDHE-RSA:+ECDHE-ECDSA:+RSA:+CURVE-ALL:+COMP-NULL’

It will lead to non-AEAD ciphers with higher priority than AEAD ciphers. However, since the spec requires TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, everything would work, so the proposal language could just be softened, but I can’t help but think this is just asking for trouble.

Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)

Glancing at OpenSSL it has the same problem

> 2. It still forbids the use of non-conforming ciphers which can only be enforced after a successful TLS negotiation if an endpoint wants to support both HTTP/1 and HTTP/2.

Yes, but this restriction only rejects non-compliant clients, that did not prioritize GCM over a prohibited cipher. 

[1] GNU-TLS default order (NORMAL priority string)

Cipher Suites (40 suites)
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
               Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
               Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
               Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
               Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
               Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
               Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
               Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
               Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
               Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
               Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
               Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
               Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
               Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
               Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
               Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
               Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005)
               Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 6 Nov 2014 10:46:40 -0800

> occur with the release of node 0.12).

How do you intend to implement it on the server-side?

....Roy

---

From: Jason Greene <[email-masked]>
Date: Thu, 6 Nov 2014 13:32:04 -0600

> On Nov 6, 2014, at 1:31 PM, Jason Greene <[email-masked]> wrote:
> 
> 
>> On Nov 6, 2014, at 1:52 AM, Greg Wilkins <[email-masked]> wrote:
>> 
>> 
>> + latency imposed by using a separate connection for fallback. Prohibited cipher suites
>> I don't think ordering helps as there may be no ciphers in intersection of client/server h2 acceptable cipher sets (as was the case when I ran jetty on java 7).    Without a robust handshake, it is impossible for a server to know at what point in the list of offered ciphers the weak fallback ciphers begin.   Many servers will never even see the list and will just see the negotiated cipher.
> 
> Assuming the ordering aspect was actually implementable, which it seems not,

That should read “universally implementable”.

---

From: Jason Greene <[email-masked]>
Date: Thu, 6 Nov 2014 13:31:03 -0600

> I don't think ordering helps as there may be no ciphers in intersection of client/server h2 acceptable cipher sets (as was the case when I ran jetty on java 7).    Without a robust handshake, it is…

Assuming the ordering aspect was actually implementable, which it seems not, the reasoning for ordering on the client is just to ensure that when a server accepts an unknown cipher it is actually not a prohibited one. Since the TLS spec requires that the preference list be followed, and since the client is also required to provide at lest TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, there will always be at least one intersection (when both ends are compliant).

Although are you talking about the handling of non-compliant clients, and that they should have a more graceful fallback?

> 
> 
> + </t> 
> + <t>
> + Servers MAY allow unknown ciphers that are negotiated by a TLS 1.2 implementation.
> + This prevents potential interoperability issues involving future ciphers supported
> + by the underlying TLS 1.2 implementation, but are not yet understood by the server.
> + Due to the restrictions on clients above, prohibited cipher suites are still
> If the server allows an unknown cipher for h2, and the client rejects it with inadequate security, then the connection will have failed - EVEN if there are acceptable ciphers if h1 was chosen.

This was basically why the order element was there, but it’s true that if you have a non-compliant client that offers the h2 alpn without ciphers it fails when h1 would have worked. 

> 
> Also note that a server might not get to choose h1 over h2 as the ALPN may be offloaded with TLS.

Sure but if its offloaded, wouldn’t the offloading use either:

a) h2c 

or

b) independent SSL stream which either drops the ALPN, or also negotiates according to the spec

---

From: Mike Bishop <[email-masked]>
Date: Thu, 6 Nov 2014 20:08:37 +0000

This is precisely our situation as well.  Our defaults are good (though our default for in-market versions aren't actually 9.2.2 compliant either; see http://support2.microsoft.com/kb/2929781 for the fully-patched Server 2012 R2 order), but we have the ability for the admin to make changes, removing or reordering as they like -- and we know that many do.  Some move lower-overhead suites higher in the list to boost throughput; others move the stronger suites to the top because they want the best security possible; still others do local swaps of two ciphersuites because there's a known bug in some client's implementation they want not to encounter.

Regardless, we don't want to constrain that ability by saying that the HTTP-layer MUST sniff out what happened and kill connections that actually work the way the admin has decided they want.  We're happy for MUST support, fine with SHOULD prefer, but enforcement will create some combination of operational breakage and confused admins.

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]] 
Sent: Thursday, November 6, 2014 10:27 AM
To: Yoav Nir
Cc: HTTP Working Group
Subject: Re: 9.2.2, Rough Consensus, and Working Code

On Nov 6, 2014, at 9:12 AM, Yoav Nir wrote:
>> I know Apache httpd won't be implementing 9.2.2 because the 
>> HTTP-aware code doesn't even get involved in connection activity 
>> until after the first HTTP message is received.  Furthermore, there 
>> is no way of knowing if an external device is securing the connection.
> Does this mean that Apache won't be enforcing the TLS requirements at all? IOW, if the configuration string for OpenSSL allows TLS_RSA_EXPORT_WITH_RC4_40_MD5 negotiated over SSLv3, httpd will be fine with this cipher and version?

The httpd interface to TLS tries to encompass many different libraries.
To the extent that such algorithm choices are available to the server, the configuration files for TLS allow the administrator to select them.
It doesn't have anything to do with the HTTP filters within httpd (the code that actually implements HTTP standards).

We occasionally disable choices within the TLS interface that have known security vulnerabilities, but we generally prefer secure defaults and shoot-your-own-foot flexibility (due to the universe of legacy platforms that httpd wants to run within that don't always have the latest features).
However, I can't really say what the SSL interface will likely support, since it is orthogonal to HTTP and depends on exactly why TLS has deprecated a given feature.  If you want to know what Apache httpd will support for HTTP/2 communication, look at what it supports for HTTP/1.

Generally speaking, if people think something is insecure of HTTP/2, it would be foolish to continue using that for HTTP/1.  However, we still need to allow such options to be configured because one of the roles of an HTTP server is to provide access to software updates.
Hence, in some circumstances, backwards compatibility does override specific security concerns because the alternative is less secure in general.

These choices are made prior to any connection, regardless of the protocol used on top of TLS.  Terminating the connection just because the client successfully negotiated a variation of TLS that isn't good enough for 9.2.2 is a stupid idea because it places me in the position of overriding the administrator's deliberate choice to configure some other (non-default) choices for TLS.  I cannot possibly guess why they made those choices, since it depends on the environment in which they are operating and the purpose of the content served.  In contrast, I know all too well that 9.2.2 is nothing more than a punt by browser vendors and a political statement by folks who have no operational responsibility.

....Roy

---

From: Mike Bishop <[email-masked]>
Date: Thu, 6 Nov 2014 20:10:53 +0000

The server administrator has learned that a particular cipher (perhaps AES-GCM) has been broken, and immediately disabled it on his machine.  TLS negotiation ends with a ciphersuite acceptable to the administrator (and his TLS config) in 20XX, but not to this working group at the end of 2014.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, November 5, 2014 4:06 PM
To: Mike Bishop
Cc: Mark Nottingham; HTTP Working Group
Subject: Re: 9.2.2, Rough Consensus, and Working Code

> if there's no required enforcement, then the others aren't really MUSTs, either.

Only if you like to play Russian Roulette.  If the others aren't MUSTs, then when you don't comply you risk getting shut down.  That's interoperability failure of a sort, is it not?

> If it rejects the client's security settings, the client can't know 
> for sure what configuration the server would accept

I don't think that this is right.  The reasons for sending INADEQUATE_SECURITY are precise, so it has to be one of those things.
You aren't allowed to send INADEQUATE_SECURITY for other reasons (that is a clarification that I'm prepared to add to #615).  Can you describe a scenario where the server would send this message and the client would be unable to determine what was wrong?

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 7 Nov 2014 08:16:17 +1100

On 7 November 2014 06:31, Jason Greene <[email-masked]> wrote:
> since the client is also required to provide at lest TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, there will always be at least one intersection (when both ends are compliant).

While I think most server implementations will strive to be compliant,
at least with there default settings,  I expect there are always going
to be situations where a deployment is configured differently (see
Roy's email) and is not compliant with 9.2.2 requirements, thus I do
not think we can assume that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
will always be present.

Thus I think a handshake that relies on the presence of any particular
cipher is fragile.  If that cipher is ever cracked and removed from
deployment, then we are going to expose the web to an unknown set of
behaviours as implementations have an assumption they relied on
removed.

cheers

---

From: Jason Greene <[email-masked]>
Date: Thu, 6 Nov 2014 15:43:19 -0600

> On Nov 6, 2014, at 3:16 PM, Greg Wilkins <[email-masked]> wrote:
> 

I hear you. My first preference is by far to completely remove 9.2.2, as it limits usage of the protocol, and ironically promotes H1. My second preference is to completely remove 9.2.2, as it is essentially an attempt dictate to TLS implementations without a TLS spec. My third preference is to replace 9.2.2 with a requirement on TLS 1.3, and hold off until its released. Extra time typically means a better protocol. My final preference is to at least get text for 9.2.2 that can actually be implemented.