Subject: #612: Adopting pull #644

From: Mark Nottingham <[email-masked]>
Date: Tue, 18 Nov 2014 16:06:45 +1100

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

We discussed this issue extensively in HNL, going into the meeting with several partial proposals that had decent support.

The result of the discussion was a blacklist-oriented approach that Martin has sketched out here: <https://github.com/http2/http2-spec/pull/644>.

I think we're able to achieve consensus on that approach (delta some possible editorial work that, if necessary, can occur afterwards), and would like to confirm that on the list.

Any further comments?

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

---

From: Mike Bishop <[email-masked]>
Date: Tue, 18 Nov 2014 08:09:00 +0000

I continue to object to the idea that HTTP/2 "MUST NOT" use the ciphers on the list, for the reasons that we, Roy, and others have outlined.

> SHOULD NOT
>   This phrase, or the phrase "NOT RECOMMENDED" mean that
>   there may exist valid reasons in particular circumstances when the
>   particular behavior is acceptable or even useful, but the full
>   implications should be understood and the case carefully weighed
>   before implementing any behavior described with this label.

The definition from 2119 reads exactly like cipher suite selection -- there may be valid reasons to use (some of) these cipher suites, but you do need to think carefully before making that choice because it's certainly not universal.  Peers who see one of these suites SHOULD send INADEQUATE_SECURITY -- the corollary to that is that these cipher suites SHOULD NOT be used.  Otherwise, we're veering into RFC 6919.

However, the gist of the pull request reflects my understanding of the room's compromise from HNL, yes.  If the WG as a whole wants to move forward with the MUST NOT, I'm willing to be in the rough here.  Close enough.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Monday, November 17, 2014 9:07 PM
To: HTTP
Subject: #612: Adopting pull #644

Any further comments?

Regards,

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 18 Nov 2014 08:13:53 +0000

--------
In message <[email-masked]>, Mark Nottingham wri
tes:

>We discussed this issue extensively in HNL, going into the meeting with 
>several partial proposals that had decent support.
>
>The result of the discussion was a blacklist-oriented approach that 
>Martin has sketched out here: 
><https://github.com/http2/http2-spec/pull/644>.

This is only even more reason to move the HTTP/2.0 mapping to TLS
to a separate document:  Now we're dictating policy.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Nov 2014 10:36:58 +0200

> On Nov 18, 2014, at 10:09 AM, Mike Bishop <[email-masked]> wrote:
> 
> The definition from 2119 reads exactly like cipher suite selection -- there may be valid reasons to use (some of) these cipher suites, but you do need to think carefully before making that choice because it's certainly not universal.  Peers who see one of these suites SHOULD send INADEQUATE_SECURITY -- the corollary to that is that these cipher suites SHOULD NOT be used.

I thought that we had decided that clients seeing these MAY send INADEQUATE_SECURITY.

Regardless, unlike MAY and MUST, you can’t just use “SHOULD” and “SHOULD NOT” in a document. They require an explanation of why you should not, and under what circumstances your are allowed to do that something that your should not do.

So, if we agree with you, we need to complete the sentence, “HTTP/2.0 clients and server SHOULD NOT use ciphers from this list unless …”

And I don’t think we’ll have consensus on “… the administrator really really wants to”.  We might get one on “… the implementation cannot control or determine the ciphersuite used by TLS”, but I don’t think we will.

Yoav

---

From: Michael Sweet <[email-masked]>
Date: Tue, 18 Nov 2014 07:23:34 -0500

Mark,

I've posted this to the issue as well...

I am concerned that we are backing ourselves into a corner here - as written, INADEQUATE_SECURITY can only be used to enforce the blacklist provided in this spec, so the error might as well be called "USE_HTTP_1_1" because that will be the result.

If, however, we want to allow INADEQUATE_SECURITY for any situation where the client or server policy prohibits the use of certain cipher suites for HTTP/2 (with the default policy being the blacklist in the spec), then this language needs to be re-worded accordingly, e.g., "Endpoints MAY choose to generate a connection error of type INADEQUATE_SECURITY if the negotiated cipher suite does not meet the endpoint's minimum security requirements. The default security requirements MUST enforce the prohibited list of cipher suites."

We should probably also better document INADEQUATE_SECURITY in section 7, something like: "The negotiated TLS cipher suite does not meet minimum security requirements (see Section 9.2)."

Finally, we should say something about why we need this functionality: endpoints typically will support both HTTP/1.1 and HTTP/2, and TLS does not allow either endpoint to restrict the list of negotiated cipher suites based on the ALPN negotiated protocol (i.e. ALPN just allows the client to send a list of protocol identifiers, not identifiers + cipher suites).

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

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Jason Greene <[email-masked]>
Date: Tue, 18 Nov 2014 12:03:14 -0600

> On Nov 18, 2014, at 2:36 AM, Yoav Nir <[email-masked]> wrote:
> 
> 

How about something like:

“unless a deployment is restricted from doing so by factors outside the scope of this document” :) 
 
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Jason Greene <[email-masked]>
Date: Tue, 18 Nov 2014 12:13:47 -0600

> On Nov 18, 2014, at 12:03 PM, Jason Greene <[email-masked]> wrote:
> 
> 

Sorry. I should have specified that I was completing a different sentence. “An endpoint SHOULD return INADEQUATE_SECURITY” ^

---

From: Yoav Nir <[email-masked]>
Date: Tue, 18 Nov 2014 20:45:00 +0200

> On Nov 18, 2014, at 8:03 PM, Jason Greene <[email-masked]> wrote:
> 

Finally, a category that includes OpenSSL APIs and the Russian government. :)

Yoav

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 19 Nov 2014 11:10:29 +1100

For me, these are the magic words in the PR:

Endpoints MAY choose to generate a <xref
target="ConnectionErrorHandler">connection
error</xref> of type <x:ref>INADEQUATE_SECURITY</x:ref> if one of the
prohibited cipher
suites are negotiated. However, implementations MUST NOT generate this
error in
reaction to the negotiation of a cipher suite that is not in the prohibited
list.
Consequently, when clients offer a cipher suite that is not prohibited,
they have to be prepared
to use that cipher suite with HTTP/2

I believe this fixes the fragile handshake problem.  It thus allows
implementers/deployers to be as rigorous or as flexible as they like in
their implementation of 9.2.2 without risking communication failure.

So despite the hacky feel of a large immutable black list, that's a erk I'm
willing to put up with if the browser implementors really do require no
extra latency on h1 connections with weak ciphers.

So looks good to me.

cheers

-- 
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: Mark Nottingham <[email-masked]>
Date: Fri, 21 Nov 2014 12:47:03 +1100

Hi Mike,

> On 18 Nov 2014, at 7:09 pm, Mike Bishop <[email-masked]> wrote:
> 

I do remember a discussion along these lines, but don't see anything in the minutes reflecting that, so it could have been a hallway chat after the meeting. IIRC making this change wasn't controversial there (but of course that's just the hallway).

What do people thing about changing this text:

"""
A deployment of HTTP/2 over TLS 1.2 MUST NOT use any of the cipher suites that are only be used with cipher suites that are listed in <xref target="BadCipherSuites"/>
"""

to a SHOULD NOT?

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Nov 2014 12:50:52 +1100

> Regardless, unlike MAY and MUST, you can’t just use “SHOULD” and “SHOULD NOT” in a document. They require an explanation of why you should not, and under what circumstances your are allowed to do t…

While it is good practice, this is not a hard and fast rule, Yoav. Certainly there has been many an RFC published with an unqualified SHOULD (or ten). 

Please don't portray your position as an absolute requirement of the IETF.

> So, if we agree with you, we need to complete the sentence, “HTTP/2.0 clients and server SHOULD NOT use ciphers from this list unless …”

"... unless the server is deployed to communicate with a known population of clients, or is willing to accept that some clients will refuse to communicate with it."

Cheers,

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Nov 2014 12:59:52 +1100

Michael,

> On 18 Nov 2014, at 11:23 pm, Michael Sweet <[email-masked]> wrote:
> 
> Mark,
> 

That's not the semantic that we're giving INADEQUATE_SECURITY, and the current use case -- informing an implementation that they're not conforming to the spec'd requirement, and therefore the client is closing the connection -- is legitimate on its own, because (as many have pointed out) USE_HTTP_1_1 used in this fashion can be viewed as a downgrade attack.

If you want to close a connection because it doesn't meet some *other*, implementation-specific requirement, you're able to do so already; if you want to flag that with an error code, you can use another error code. 

I don't detect any appetite in the rest of the WG for defining that now, however. 

> We should probably also better document INADEQUATE_SECURITY in section 7, something like: "The negotiated TLS cipher suite does not meet minimum security requirements (see Section 9.2)."

It's used for other things too...

> Finally, we should say something about why we need this functionality: endpoints typically will support both HTTP/1.1 and HTTP/2, and TLS does not allow either endpoint to restrict the list of nego…

I think that's good editorial input for Martin.

Cheers,

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 21 Nov 2014 13:42:52 +1100

On 21 November 2014 12:47, Mark Nottingham <[email-masked]> wrote:

> A deployment of HTTP/2 over TLS 1.2 MUST NOT use any of the cipher suites
> that are only be used with cipher suites that are listed in <xref
> target="BadCipherSuites"/>
> """
>
> to a SHOULD NOT?
>

Hmmm that text is kind of jibberish anyway.  It needs review!

Maybe:
A deployment of HTTP/2 over TLS 1.2 MUST NOT use any of the cipher suites
that are listed in <xref target="BadCipherSuites"/>

But for the actual intent, I'm OK with either MUST NOT or SHOULD NOT

cheers

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Nov 2014 13:47:33 +1100

Not at my desk, but I think that was my cut and paste error - sorry. 

Sent from my iPhone

> On 21 Nov 2014, at 1:42 pm, Greg Wilkins <[email-masked]> wrote:
> 
> 
> A deployment of HTTP/2 over TLS 1.2 MUST NOT use any of the cipher suites that are listed in <xref target="BadCipherSuites"/>
> 
> Greg Wilkins <[email-masked]>  @  Webtide - an Intalio subsidiary

---

From: Yoav Nir <[email-masked]>
Date: Fri, 21 Nov 2014 06:57:55 +0200

> On Nov 21, 2014, at 3:50 AM, Mark Nottingham <[email-masked]> wrote:
> 

Not hard and fast, but recently it’s been a good way of getting gen—art comments and DISCUSSes.

> "... unless the server is deployed to communicate with a known population of clients, or is willing to accept that some clients will refuse to communicate with it.”

WFM

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Nov 2014 21:05:29 -1000

On 20 November 2014 21:05, Martin Thomson <[email-masked]> wrote:
> tl;dr: new PR:

Just updated, actually: https://github.com/http2/http2-spec/pull/644

---

From: Martin Thomson <[email-masked]>
Date: Thu, 20 Nov 2014 21:05:06 -1000

tl;dr: new PR:
> A deployment of HTTP/2 over TLS 1.2 MUST NOT use any of the cipher suites that are only be used with cipher suites that are listed in <xref target="BadCipherSuites"/>

I've prepared the draft with a SHOULD.  And noted the risks...

>> Regardless, unlike MAY and MUST, you can’t just use “SHOULD” and “SHOULD NOT” in a document. They require an explanation of why you should not, and under what circumstances your are allowed to do…
[...]
> "... unless the server is deployed to communicate with a known population of clients, or is willing to accept that some clients will refuse to communicate with it."

I've not chosen that precise form (it's clunky without the connection
error being introduced).  But I think that I've framed it in a way
that should avoid a DISCUSS target.

> I think that's good editorial input for Martin.

Text to that effect has been in the document for ages, though it was
removed in the PR.  I'll try to find a way to have it return in some
fashion.

...I've also tried to fix some wording contortions around the TLS
1.2/1.3+ split here.

---

From: Jason Greene <[email-masked]>
Date: Fri, 21 Nov 2014 01:12:33 -0600

> On Nov 21, 2014, at 1:05 AM, Martin Thomson <[email-masked]> wrote:
> 
> tl;dr: new PR:

+1 thanks guys, this looks good.

---

From: Jason Greene <[email-masked]>
Date: Fri, 21 Nov 2014 01:12:32 -0600

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Nov 2014 18:12:37 +1100

Thanks, Martin.

Folks, please have a read -- and note the SHOULD language. Barring new information, I think this is where consensus lies.

Regards,

> On 21 Nov 2014, at 6:05 pm, Martin Thomson <[email-masked]> wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 21 Nov 2014 18:15:55 +1100

BTW, for reviewing, I use:
  https://github.com/http2/http2-spec/pull/644/files
... selecting the "split" view and turning off "Show notes".

YMMV.

---

From: Patrick McManus <[email-masked]>
Date: Fri, 21 Nov 2014 13:29:53 -0500

Its not actually part of the change list, but we say "Implementations of
HTTP/2 MUST support <xref target="TLS12">TLS 1.2</xref> for HTTP/2 over
TLS."..

I think we actually mean must only use versions >= TLS 1.2

1] tls-1.2-die-die-die is certainly a possibility down the road
2] support is more ambiguous than "use"..  let's not leave room for some
kind of twisted reading in favor ssl3 intolerance fallback just because
each side supports 1.2.

hth.

On Fri, Nov 21, 2014 at 2:15 AM, Mark Nottingham <[email-masked]> wrote:

> >> A deployment of HTTP/2 over TLS 1.2 MUST NOT use any of the cipher
> suites that are only be used with cipher suites that are listed in <xref
> >>> Regardless, unlike MAY and MUST, you can’t just use “SHOULD” and
> “SHOULD NOT” in a document. They require an explanation of why you should
> not, and under what circumstances your are allowed to do that something
> that your should not do.
> >>
> > [...]
> >>> So, if we agree with you, we need to complete the sentence, “HTTP/2.0
> clients and server SHOULD NOT use ciphers from this list unless …”
> >>
> >> "... unless the server is deployed to communicate with a known
> population of clients, or is willing to accept that some clients will
> refuse to communicate with it."
> >
> >>> Finally, we should say something about why we need this functionality:
> endpoints typically will support both HTTP/1.1 and HTTP/2, and TLS does not
> allow either endpoint to restrict the list of negotiated cipher suites
> based on the ALPN negotiated protocol (i.e. ALPN just allows the client to
> send a list of protocol identifiers, not identifiers + cipher suites).
> >>

---

From: Mike Sweet <[email-masked]>
Date: Fri, 21 Nov 2014 18:06:45 -0500

Wfm 

Sent from my iPhone

> On Nov 20, 2014, at 8:47 PM, Mark Nottingham <[email-masked]> wrote:
> 
> Hi Mike,
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 21 Nov 2014 14:41:20 -1000

> 1] tls-1.2-die-die-die is certainly a possibility down the road

It's a meme.

> kind of twisted reading in favor ssl3 intolerance fallback just because each
> side supports 1.2.

MUST use 1.2 or higher, check.

---

From: Mike Bishop <[email-masked]>
Date: Sat, 22 Nov 2014 00:55:44 +0000

Speaking for the Microsoft folks, we're content.

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]] 
Sent: Thursday, November 20, 2014 11:13 PM
To: Martin Thomson
Cc: Mike Bishop; HTTP
Subject: Re: #612: Adopting pull #644

Thanks, Martin.

Regards,

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 25 Nov 2014 10:26:16 +1100

It seems that we have consensus here. Marking as editor-ready.

> On 18 Nov 2014, at 4:06 pm, Mark Nottingham <[email-masked]> wrote:
>