Subject: #612: 9.2.2 and ALPN

From: Mark Nottingham <[email-masked]>
Date: Tue, 11 Nov 2014 16:03:35 -1000

We had a wide-ranging discussion in about this issue in Honolulu today. After an introductory presentation <http://httpwg.github.io/wg-materials/ietf91/922.pdf>, and then much discussion/iteration, we ended up with this on the screen:

-8<-
If the ciphersuite selected for h2 is...
BAD = peer MAY INADEQUATE_SECURITY
!BAD = peer MUST NOT INADEQUATE_SECURITY

Peers probably shouldn't negotiate BAD

where BAD is a fixed in-spec blacklist
->8-

Using the straw-man proposal on the last page of the PDF, this implies #5 (relax requirement to generate INADEQUATE_SECURITY) and a modification of #2 (Nominate a fixed list of suites for use with H2+TLS12) to a blacklist rather than a whitelist.

Not explicit here but implied (and seemingly not controversial) were #1 (making all cipher suite requirements specific to TLS 1.2), #3 (keep the required interop suite as mandatory to deploy) and #4 (Clarify that cipher suite requirements apply to deployments, not impl).

Note that there is NOT a requirement to use or not use particular cipher suites; only a prose note that if you do so, you may encounter problems. This is somewhat in the spirit of #4.

#6 didn’t seem to get significant support, so I think the plan is to drop it.

Martin is going to prepare a pull request with exact text, using the requirements currently in 9.2.2 to create the blacklist.

Based on the reaction in the meeting (which included some but not all stakeholders) as well as some 1-to-1 discussions I’ve had with people who weren’t there, I believe that this is likely to be as close to a consensus position that we can get. 

Please ask comment or questions if need be, and indicate your support or lack thereof (now if you’re comfortable doing that, or after Martin shows exact text).

Regards,

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Nov 2014 16:29:17 -1000

I think making a ciphersuite “mandatory to deploy” is weird. In Russia, all traffic for certain kinds of information (financial, personnel records, etc) is required to be encrypted using GOST-sanctioned algorithms. 

A requirement like this would mean that what they’ll be doing in Russia is somehow “not HTTP/2” even though it looks exactly the same as HTTP/2. Mandatory to implement is fine, but turning HTTP/2 into "not-HTTP/2" because of the configuration of the TLS server seems wrong.

> On Nov 11, 2014, at 4:03 PM, Mark Nottingham <[email-masked]> wrote:
>

---

From: Brian Smith <[email-masked]>
Date: Tue, 11 Nov 2014 18:38:36 -0800

> Not explicit here but implied (and seemingly not controversial) were #1 (making all cipher suite requirements specific to TLS 1.2), #3 (keep the required interop suite as mandatory to deploy) and #…

To clarify #3 and #4: If a server only has an ECDSA certificate, then
it shouldn't be required to (and in fact, cannot) implement
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. I believe that
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 should be mandatory if the
certificate is RSA and TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 if the
certificate is ECDSA, because that is implying that having an RSA
certificate is mandatory, and that's not good. Also, as a practical
matter, in a few years it is likely to be the case that
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 is the most interoperable
cipher suite for servers to support, because Windows 7's SChannel
supports it, but Windows 7's SChannel does not support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. And, in practice, all browsers
that support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 also support
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256.

Cheers,
Brian

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 12 Nov 2014 15:58:43 +1100

> where BAD is a fixed in-spec blacklist

That looks very encouraging.   An in-spec blacklist for BAD ciphers
together to the !BAD==MUST NOT INADEQUATE_SECURITY, I think is a good
compromise.  It mostly addresses the fragile handshake concern while
allowing h1 fallback without additional latency.

I assume that there is an implied:

  BAD = peer MAY fallback to h1 (if able to influence ALPN protocol
selection)

and that will not be seen as a downgrade attack (or at least and acceptable
one).

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: "Albert Lunde" <[email-masked]>
Date: Wed, 12 Nov 2014 07:39:26 -0600

>BAD = peer MAY fallback to h1 (if able to influence ALPN protocol selection)

>and that will not be seen as a downgrade attack (or at least and acceptable one).

So long as  some servers treat HTTP/1.1 and HTTP/2.0 as interchangeable, retrying requests as HTTP/1.1 could constitute a downgrade attack

In other news, on the hopeful side, Microsoft just back-ported TLS 1.2  GCM ciphers to more OS platforms while fixing a  SChannel bug

-- 

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: Ryan Hamilton <[email-masked]>
Date: Wed, 12 Nov 2014 08:27:32 -0800

> and that will not be seen as a downgrade attack (or at least and

Can you explain why this would be desirable? It sure sounds like a
downgrade attack path to me.

---

From: Mike Bishop <[email-masked]>
Date: Wed, 12 Nov 2014 17:59:27 +0000

Implementations might choose to handle that failure in any of several heuristics, which are outside the scope of the h2 spec.  Another reasonable response might be trying again, offering only !BAD ciphers, for example, now that you know the server supports h2 (and thus, hopefully, the MTI ciphersuite).

From: Greg Wilkins [mailto:[email-masked]]
Sent: Tuesday, November 11, 2014 8:59 PM
To: Mark Nottingham
Cc: HTTP Working Group
Subject: Re: #612: 9.2.2 and ALPN

On 12 November 2014 13:03, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:

-8<-

That looks very encouraging.   An in-spec blacklist for BAD ciphers together to the !BAD==MUST NOT INADEQUATE_SECURITY, I think is a good compromise.  It mostly addresses the fragile handshake concern while allowing h1 fallback without additional latency.
I assume that there is an implied:
  BAD = peer MAY fallback to h1 (if able to influence ALPN protocol selection)
and that will not be seen as a downgrade attack (or at least and acceptable one).
cheers

--
Greg Wilkins <[email-masked]<mailto:[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: Mike Bishop <[email-masked]>
Date: Wed, 12 Nov 2014 18:56:11 +0000

I think this is moving in a better direction, but Yoav's note is one of the biggest reasons why I think rather than trying to introduce a new concept of "mandatory to deploy," we should use the well-tested model of MUST implement, SHOULD use.  This is one of many situations in which a deployment will know better than this WG which ciphers are appropriate to their environment.  SHOULD means that if you don't, you're likely to have interop pain, which seems exactly applicable here.  If you have local knowledge that leads you to depart from this behavior, you do that knowing clients outside your control won't talk to you as easily.

Also, having the spec mandate *capabilities of the TLS stack you choose* and *HTTP/2 behaviors based on the TLS outcome* makes me much happier than having the spec mandate behaviors that happen inside the TLS stack.  Let's keep the layers clean.

---

From: "Simpson, Robby (GE Energy Management)" <[email-masked]>
Date: Wed, 12 Nov 2014 20:17:11 +0000

On 11/12/14, 1:56 PM, "Mike Bishop" <[email-masked]> wrote:

>I think this is moving in a better direction, but Yoav's note is one of
>the biggest reasons why I think rather than trying to introduce a new
>concept of "mandatory to deploy," we should use the well-tested model of
>MUST implement, SHOULD use.  This is one of many situations in which a
>deployment will know better than this WG which ciphers are appropriate to
>their environment.  SHOULD means that if you don't, you're likely to have
>interop pain, which seems exactly applicable here.  If you have local
>knowledge that leads you to depart from this behavior, you do that
>knowing clients outside your control won't talk to you as easily.

I've stayed silent thus far on this topic because I do applaud the efforts
and concerns for securing the big 'I' Internet and the big 'W' Web.

However, in the embedded world, I think we will be using the RFC 7251
cipher suites (e.g., TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8) exclusively, at
least for some time, due to the built-in hardware support for CCM.

So, I would encourage a re-think on the MTI/MTD language and possibly even
slackening the requirements language ala Roy's comments in Honolulu.

- Robby

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 13 Nov 2014 08:50:02 +1100

> downgrade attack path to me.

Well I'm not the advocate for this "feature", just trying to better define
it.     In the h2-14 draft, the final paragraph of
9.2.2 allows for weak ciphers that are unacceptable to h2 to be included in
the handshake so that h1 servers that do not use h2 or strong ciphers can
be connected to without additional round trips.        This has been the
basis of the fragile handshake problem that I have raised as a server could
never really tell if a cipher was being offered for h2 or not and thus was
faced with the prospect of INADEQUATE_SECURITY if it tried h2 on an unknown
cipher.

My understanding of the current proposal is to remove the doubt associated
with the handshake by providing an in spec black list of ciphers.   So my
message was to clarify if those black listed ciphers are there so that they
may be offered in the initial handshake, but only for the purposes of h1
fallback.

So I'm trying to clarify what I server should do if it's TLS layer
negotiates a cipher on the BAD list.   The text that Mark proposes says
that it MAY send INADEQUATE_SECURITY, which means that it may not.   In the
case that it does not send it, I'm assuming that is for the h1 fallback
case and think that needs to be called out in the text.

I think it is a downgrade attack vector, but what I think this WG is trying
to say is that it is an acceptable one.  If either peer wants to avoid it,
they simple need to not offer the bad ciphers.

cheers

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Nov 2014 12:40:16 -1000

On Wed, Nov 12, 2014 at 11:50 AM, Greg Wilkins <[email-masked]> wrote:

> 9.2.2 allows for weak ciphers that are unacceptable to h2 to be included
> in the handshake so that h1 servers that do not use h2 or strong ciphers
> can be connected to without additional round trips.        This has been
> the basis of the fragile handshake problem that I have raised as a server
> could never really tell if a cipher was being offered for h2 or not and
> thus was faced with the prospect of INADEQUATE_SECURITY if it tried h2 on
> an unknown cipher.
>

Yes.

> negotiates a cipher on the BAD list.
>

I assume you mean that it negotiates h2 and also negotiates a BAD cipher?
Since
if it's h1, it can just proceed with the handshake and everything should be
fine.

>   The text that Mark proposes says that it MAY send INADEQUATE_SECURITY,
> which means that it may not.   In the case that it does not send it, I'm
> assuming that is for the h1 fallback case and think that needs to be called
> out in the text.
>

Well, it certainly send INADEQUATE_SECURITY, but I think that that
MAY is primarily about the client. The bottom line here is that if a server
selects h2 and a BAD cipher suite, it is exposing itself to undefined
behavior from the client in the form of the client terminating the
connection with INADEQUATE_SECURITY.

> they simple need to not offer the bad ciphers.

Can you please explain how this downgrade attack works?

-Ekr

cheers

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Nov 2014 16:20:03 -1000

On Nov 12, 2014, at 12:40 PM, Eric Rescorla wrote:
> So I'm trying to clarify what I server should do if it's TLS layer negotiates a cipher on the BAD list. 
> 
> I assume you mean that it negotiates h2 and also negotiates a BAD cipher? Since
> if it's h1, it can just proceed with the handshake and everything should be fine.
>  
>   The text that Mark proposes says that it MAY send INADEQUATE_SECURITY, which means that it may not.   In the case that it does not send it, I'm assuming that is for the h1 fallback case and think that needs to be called out in the text.
> 

Yes, though I don't see why that would be considered exposing itself.
The client can close the connection at any time.  Since the client is
the party that doesn't like the chosen cipher, it is free to
make another connection attempt using only good ciphers.

I don't think there is any scenario in which INADEQUATE_SECURITY
needs to be sent.  A server that wanted to send it would have refused
the TLS handshake (i.e., no good ciphers offered).  A server that doesn't
want to send it isn't going to.  A client that does want to send it
doesn't need to -- just drop the connection.  A client that doesn't want
to send it is just going to make use of the completed connection, either
to send an HTTP/1 request or to ignore 9.2.2 and send h2.

....Roy

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Nov 2014 16:41:35 -1000

> make another connection attempt using only good ciphers.

I don't believe that either Chrome or Firefox intends to do this, in which
case servers which behaved in this way will simply not be able to talk
to those browsers.

-Ekr

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Nov 2014 17:12:27 -1000

> case servers which behaved in this way will simply not be able to talk

No, the servers will be able to talk just fine.  The client will just
not receive the response, which is true of a fairly significant
percentage of client requests regardless.

If the h2 server was able to control this exchange, then they wouldn't
allow a bad cipher to be selected.

....Roy

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Nov 2014 17:38:06 -1000

> percentage of client requests regardless.

I think we may be talking past each other. A server that behaves this way
will
simply appear as broken to every user of every client which behaves
as I indicated above. I suspect that may not be what they wanted.

-Ekr

---

From: Jason Greene <[email-masked]>
Date: Wed, 12 Nov 2014 23:03:12 -0600

Thank you everyone in Honolulu for working up this compromise. This approach addresses my major concern, which was that 9.2.2 was not widely implementable, leading to unnecessary interop problems. 

> On Nov 11, 2014, at 8:03 PM, Mark Nottingham <[email-masked]> wrote:
> 

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

---

From: Jason Greene <[email-masked]>
Date: Wed, 12 Nov 2014 23:09:57 -0600

I agree that this would be the best way to specify this new approach. The reality is even if stricter language is used, it won’t be any more enforceable than what you propose. Perhaps this is already what Martin intended to specify?

> On Nov 12, 2014, at 12:56 PM, Mike Bishop <[email-masked]> wrote:
>

---

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

> On Nov 12, 2014, at 4:40 PM, Eric Rescorla <[email-masked]> wrote:
> 
>> I think it is a downgrade attack vector, but what I think this WG is trying to say is that it is an acceptable one.  If either peer wants to avoid it, they simple need to not offer the bad ciphers.
>> 

In order to deal with servers which, perhaps mistakenly, accept non-h2 compliant ciphers, a client has to choose between failing the connection entirely (when H1 would have worked fine), or opening a new connection. If that new connection offers a weaker selection of ciphers (perhaps some kind of fallback to an old code path) it becomes a potential target.

---

From: Jason Greene <[email-masked]>
Date: Wed, 12 Nov 2014 23:46:33 -0600

> On Nov 12, 2014, at 9:12 PM, Roy T. Fielding <[email-masked]> wrote:
> 

The other possibility is that if the ALPN implementation provides access to the TLS stack’s intended chosen cipher (or alternatively the list of ciphers in the ClientHello, which can be used to derive the chosen cipher), the h2 stack can select H1, preventing the connection from failing.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 12 Nov 2014 19:58:45 -1000

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

Even if you fall back to HTTP/1, there is no reason to avoid offering the strongest ciphers you can. Browsers have been offering weird ciphersuites for years: Firefox has camelia, there are two kinds of SCSV, GOST plug-ins in Russia. The web is mostly tolerant of unknown ciphersuites. So falling back to ALPN with only h1 or no ALPN at all with both preferred and not-so-preferred ciphersuites should work.

Besides, IMO the fallback should be different. If the client offers h1 or h2, and both AES-GCM and 3DES-CBC, and the server comes back with h2 + 3DES-CBC, then a browser that wishes to follow 9.2.2 MAY send an INADEQUATE_SECURITY, and follow that with another attempt, offering only h2 and only AES-GCM (or any other “while-list” ciphersuite). We already know that the server supports h2, so supposedly it does support the mandatory to implement  ciphersuite, but it has trouble selecting the right one when given too much choice (call it the embarras du choix bug), so proposing only h2 with acceptable ciphersuites might work. 

If it doesn’t than the client has a choice of h2 with a not-so-preferred ciphersuite (which is not allowed by the spec) or h1 with the same not-so-preferred ciphersuite (which the spec is silent about, because this is a spec for h2, not h1).

Yoav

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Nov 2014 21:31:09 -1000

On Nov 12, 2014, at 5:38 PM, Eric Rescorla wrote:
> I think we may be talking past each other. A server that behaves this way will

I am well aware of what you are stating.  It is simply wrong.  Such a
client has a bug because it requested a secure session using what it
considers an insecure cipher.  If the client sends an h2 request on that
connection, I simply don't care how badly they break when they get an
h2 response.  The h2 server isn't going to do anything about it because
it has no control over the chosen ciphers.

The client is fully capable of interop in that case.  If it chooses not
to try again with a good cipher, then it has failed its own user.

....Roy

---

From: Yoav Nir <[email-masked]>
Date: Wed, 12 Nov 2014 21:56:11 -1000

> On Nov 12, 2014, at 9:31 PM, Roy T. Fielding <[email-masked]> wrote:
> 
> considers an insecure cipher.  

Hi, Roy

Much as I agree with you about section 9.2.2 and the behavior that it prescribes being inappropriate for this document, the working group has considered this argument months ago, and then again weeks ago and rejected it.

What’s more, I don’t think anyone has argued that TLS_RSA_WITH_AES_128_CBC_SHA is insecure when used with TLS 1.2. It is a fine, secure ciphersuite. Nevertheless, the CBC construction has in the past been a source of vulnerabilities, all of which could be worked around, but which required changes to deployed products. GCM-based ciphersuites are faster and AEAD constructions are considered to have more robust security. That is not to say that TLS_RSA_WITH_AES_128_GCM is more secure than TLS_RSA_WITH_AES_128_CBC_SHA, just that we believe the likelihood of the next BEAST, LUCKY13 or POODLE happening in the latter is much greater than the likelihood of it happening in the former. For this reason the working group has decided that the new protocol HTTP/2 will use only AEAD ciphersuites.

Would you object less if the error code was named INAPPROPRIATE_SECURITY rather than INADEQUATE_SECURITY ?

> If the client sends an h2 request on that

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 12 Nov 2014 22:32:48 -1000

> Much as I agree with you about section 9.2.2 and the behavior that it prescribes being inappropriate for this document, the working group has considered this argument months ago, and then again wee…

No, it didn't.  The part of the working group that actually implements
servers for use by others agrees with me.  The chair and the IESG
do not.  The compromise that Mark posted is "good enough" because it
simply presents the likely interop failure that Ekr described, instead
of requiring that an h2 server do something about it.

Unfortunately, this is a case where the spec will end up saying
some things that are simply ignored by implementations, since it isn't
the HTTP server's responsibility to override or even second-guess the
TLS configuration. In most cases it won't matter, since the same
servers willing to deploy h2 are the ones most likely to have admins
that prefer stronger ciphersuites.

> What’s more, I don’t think anyone has argued that TLS_RSA_WITH_AES_128_CBC_SHA is insecure when used with TLS 1.2. It is a fine, secure ciphersuite. Nevertheless, the CBC construction has in the pa…

That isn't something the WG can decide for others.  Admins might follow
that recommendation, but it is far outside the scope of HTTP.

> Would you object less if the error code was named INAPPROPRIATE_SECURITY rather than INADEQUATE_SECURITY ?

It doesn't matter -- the connection is irrelevant as soon as it is closed.

....Roy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Thu, 13 Nov 2014 08:37:15 +0000

--------
In message <[email-masked]>, Yoav Nir writes:

>Would you object less if the error code was named INAPPROPRIATE_SECURITY =
>rather than INADEQUATE_SECURITY ?

I would find UNDESIRABLE_SECURITY much more appropriate given that this
is a value judgment about which reasonable experts in the field might
disagree.

-- 
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: "Albert Lunde" <[email-masked]>
Date: Thu, 13 Nov 2014 09:22:01 -0600

>So long as  some servers treat HTTP/1.1 and HTTP/2.0 as interchangeable, retrying requests as HTTP/1.1 could constitute a downgrade attack

My concern about downgrades is I suppose philosophical: at this point it doesn’t seem that TLS+HTTP/1.1 vs TLS+HTTP/2.0 are that different in terms of potential security vulnerabilities. The idea that security risks are somehow less important when retrying under HTTP/1.1 seems to be sweeping them under the rug, I’m not an implanter, just a long term bystander, so you may take my two cents for what it’s worth.

The target of choice seems to be cookies or http session keys, and the most powerful vector seems to be iterated attacks executed with JavaScript and other active context; these factors aren’t that different between HTTP versions. 

Isolating cookies or TLS keys to only apply to HTTP/2.0 or HTTP/1.1 could be a meaningful security distinction, but it would break things and slow adoption, I suppose. And it would be yet another hack to make active content “safe”.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Nov 2014 06:34:48 -1000

On Wed, Nov 12, 2014 at 7:27 PM, Jason Greene <[email-masked]>
wrote:

> >> I think it is a downgrade attack vector, but what I think this WG is
> trying to say is that it is an acceptable one.  If either peer wants to
> avoid it, they simple need to not offer the bad ciphers.
> >>
> In order to deal with servers which, perhaps mistakenly, accept non-h2
> compliant ciphers, a client has to choose between failing the connection
> entirely (when H1 would have worked fine), or opening a new connection. If
> that new connection offers a weaker selection of ciphers (perhaps some kind
> of fallback to an old code path) it becomes a potential target.

Can you explain how the attacker exploits that?

-Ekr

---

From: Jason Greene <[email-masked]>
Date: Thu, 13 Nov 2014 12:12:10 -0600

> On Nov 13, 2014, at 10:34 AM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
> On Wed, Nov 12, 2014 at 7:27 PM, Jason Greene <[email-masked]> wrote:
> 

A contrived example is that client that didn’t previously support fallback, adds code for fallback due to this aspect of the spec. The code for fallback assumes any connection establishment failure should result in a retry. The attacker can then do something like in POODLE, and just MITM abort the connection.

It’s easily preventable:
1. Send the same or stronger suites on retry (e.g. h2-only)
2. Take care to ensure retry only occurs after INADEQUATE_SECURITY is received

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Nov 2014 08:59:34 -1000

On Thu, Nov 13, 2014 at 8:12 AM, Jason Greene <[email-masked]>
wrote:

> A contrived example is that client that didn’t previously support
> fallback, adds code for fallback due to this aspect of the spec. The code
> for fallback assumes any connection establishment failure should result in
> a retry. The attacker can then do something like in POODLE, and just MITM
> abort the connection.
>

OK, but the problem is that code. You should only be falling back on
INADEQUATE_SECURITY, not negotiation failure, precisely because
the former is authenticated and the latter is not.

-Ekr

---

From: Greg Wilkins <[email-masked]>
Date: Fri, 14 Nov 2014 09:22:27 +1100

> to send an HTTP/1 request or to ignore 9.2.2 and send h2.

I think there are still a few scenarios that INADEQUATE_SECURITY can be
sent - but thankfully not many.

If the server offloads both TLS and ALPN, then both the cipher and protocol
choice may be made for it.   If the offloader selects a cipher in the BAD
set and h2, then the server can choose to fail the connection  or try it's
hand and see if the client will accept it or fail it.

In both cases, if the connection is failed, sure it can just be closed...
but I think it is more informative to send the INADEQUATE_SECURITY
code.       Hopefully this is now a very unlikely case, so when it does
happen having a sign post to say why will be very useful.

For me, the most important thing is that with the immutable black list of
BAD ciphers, a server now does not have to guess if the client was offering
a cipher for h1 only.   It has much better knowledge about the situation it
may find itself in.  It may still be constrained by limitations of TLS/ALPN
implementations, but that is still much better than not being constrained
and not knowing if a cipher will be accepted or not.

Note also, with a well defined h2 black list, then the scenario about can
be made even less likely by offloaders that implement ALPN having a special
case for the h2 black list.    I think it would have been unlikely that
offloaders would have implemented 9.2.2, but it is more likely that some
will provide a simple h2 black list, as it is far simpler to implement and
immutable.     It is still a hack, but at least now the hack is for the old
ciphers and old protocol and in 10 years time implementations will probably
be able to drop support for it and function perfectly ok.

cheers

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Nov 2014 16:03:45 -0800

I've been struggling to find time for making this change, but I have a
first sketch of the text for this.  I think that this is perfectly
workable.

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

There is one piece of collateral damage here that I think we will have
to decide on.  The draft previously has requirements for key strength
on DHE and ECDHE.  I've moved that to 9.2.1.  I want to make sure that
I call that out.

The list is fairly long.  I've tried to faithfully apply the rules we
agreed previously to build the list (!PFS or Stream or Block) based on
the current IANA registry.  If anyone cares to double-check it, please
let me know if I've messed up somehow.

---

From: "Eric J. Bowman" <[email-masked]>
Date: Thu, 13 Nov 2014 19:18:26 -0700

Top of my To-Not-Do list, is chiming in on 9.2.2; but oh, well...

Greg Wilkins <[email-masked]> wrote:
>
> Roy T. Fielding <[email-masked]> wrote:
> 
> > needs to be sent.  A server that wanted to send it would have
> > refused the TLS handshake (i.e., no good ciphers offered).  A
> > server that doesn't want to send it isn't going to.  A client that
> > does want to send it doesn't need to -- just drop the connection.
> > A client that doesn't want to send it is just going to make use of
> > the completed connection, either to send an HTTP/1 request or to
> > ignore 9.2.2 and send h2.
> >
>

I have to agree with Roy on this one. Inadequate vs. Inappropriate is a
moot point; I'd never send either, vs. closing the connection.

> 
> I think there are still a few scenarios that INADEQUATE_SECURITY can
> be sent - but thankfully not many.
> 

I can't think of one, despite your examples. I've done enough httpd work
since 1994 that I don't see why I'd bother to tell any client *why* I'm
dropping a connection, rather than just dropping it. My httpd code just
doesn't include such subroutines, and I can't see changing that for any
reason.

> 
> In both cases, if the connection is failed, sure it can just be
> closed... but I think it is more informative to send the
> INADEQUATE_SECURITY code.
> 

Sorry Greg, but I'd say "more stupid" rather than "more informative". My
security knowledge lags behind plenty of others on this list, let alone
the black hats, and I don't see that changing. So my perspective is, why
give anyone clues?

I'd rather give a long-winded response, but, you either get that or you
don't. Not everyone who implements HTTP has Eric's or Roy's knowledge,
all we can do is not be stupid. Like by telling clients why our servers
won't talk to them. You either get why that would be stupid, or you
don't. I, for one, will never get why it wouldn't be. I'm far too set in
my ways on that.

>
> It is still a hack, but at least now the hack is for the old ciphers
> and old protocol and in 10 years time implementations will probably

Mmmm hmmm. I'm too conservative about unprovable notions of the future,
to implement hacks (security holes) today. Yeah, yeah, I support Roy too
much, I don't have a horse in this race as my current project is
building a dude ranch, etc... But, quitting HTTP is proving as difficult
as quitting smoking.

And I know a bad idea when I see one. Believe me, I'd rather be all rah-
rah about h2 than I am. This is just yet another reason for my bad
attitude, and continued posting here despite having left the industry.

Re-lurking now, and having a smoke, despite knowing it's bad for me. ;-)

-Eric

---

From: "Eric J. Bowman" <[email-masked]>
Date: Thu, 13 Nov 2014 19:31:00 -0700

"Roy T. Fielding" <[email-masked]> wrote:
> > MAY is primarily about the client. The bottom line here is that if
> > a server selects h2 and a BAD cipher suite, it is exposing itself
> > to undefined behavior from the client in the form of the client
> > terminating the connection with INADEQUATE_SECURITY.
> 

Neither do I. But, we didn't see why anything else that's been
exploited would be considered exposure, either. Which is why I'm
against protocol chatter offering hints about what's secure and what
isn't. Call it a gut feeling.

Aside from the practical notion that specifics about TLS handshaking
seem out-of-scope re: HTTP.

-Eric

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Nov 2014 16:40:24 -1000

> On Nov 13, 2014, at 4:18 PM, Eric J. Bowman <[email-masked]> wrote:
> 

Assuming that receiving the error code generates a log, while RST-ing the connection is chalked up to network glitch, it could provide information to the administrator to somehow reconfigure the server to make the logs go away.

Yoav

---

From: "Eric J. Bowman" <[email-masked]>
Date: Thu, 13 Nov 2014 20:02:37 -0700

Yoav Nir <[email-masked]> wrote:
> 
> > I have to agree with Roy on this one. Inadequate vs. Inappropriate
> > is a moot point; I'd never send either, vs. closing the connection.
> 
> Assuming that receiving the error code generates a log, while RST-ing
> the connection is chalked up to network glitch, it could provide
> information to the administrator to somehow reconfigure the server to
> make the logs go away.
> 

Which would be a bad thing, how? I'm a server guy, so my gut instinct
is that client-based bad outcomes are more worrisome. More bad-actor
clients than servers, IMO, but I lack statistical backing. Feel free to
enlighten me, because honestly, I get in over my head on the pros and
cons of TLS_RSA_WITH_AES_128_GCM vs. TLS_RSA_WITH_AES_128_CBC_SHA and
such.

What I do (think I) know, is that these intricacies are best not
exposed. Because the client can always close the connection and try
again, without the whole world knowing why. Or maybe I'm smoking the
wrong kind of cigarettes -- I do live in Colorado, you know... ;-)

-Eric

---

From: Martin Thomson <[email-masked]>
Date: Thu, 13 Nov 2014 19:12:14 -0800

> on DHE and ECDHE.  I've moved that to 9.2.1.  I want to make sure that

On consideration (and feedback on github), I've changed this to
include permission to use INADEQUATE_SECURITY in the case that the
minimum key sizes are not negotiated.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 13 Nov 2014 17:13:58 -1000

> On Nov 13, 2014, at 5:02 PM, Eric J. Bowman <[email-masked]> wrote:
> 
> is that client-based bad outcomes are more worrisome.

I missed that part. I took your “I’d never send either” as being client-side, so I offered a case where there is utility in sending.

> More bad-actor

---

From: Mike Bishop <[email-masked]>
Date: Fri, 14 Nov 2014 07:39:11 +0000

I would think the client MAY send INADEQUATE_SECURITY if any of the requirements in either section aren't honored.  For example, say the server selects TLS 1.1.

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Thursday, November 13, 2014 7:12 PM
To: Mark Nottingham
Cc: HTTP Working Group
Subject: Re: #612: 9.2.2 and ALPN

> on DHE and ECDHE.  I've moved that to 9.2.1.  I want to make sure that 

On consideration (and feedback on github), I've changed this to include permission to use INADEQUATE_SECURITY in the case that the minimum key sizes are not negotiated.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 14 Nov 2014 00:18:48 -0800

> I would think the client MAY send INADEQUATE_SECURITY if any of the requirements in either section aren't honored.  For example, say the server selects TLS 1.1.

In this case, the distinction between MAY and SHOULD is basically
irrelevant.  Anything short of MUST NOT provides an incentive for
servers to comply with the restriction that the error is enforcing,
while anything short of MUST in the other direction allows for this to
play out in the marketplace.  That's something that we've resorted to
regarding http and https usage in HTTP/2.

Dave is sort of correct over the usage based on a strict
interpretation of 2119, but the colloquial usage of MAY - and that of
many IETF documents - establishes much a less-strict meaning for the
word.  I don't use should because that invokes the other 2119
guidance, which is equally incompatible.