Subject: Updated 9.2

From: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 10:41:48 -0700

I've updated my pull request to include some of Greg's editorial
feedback, as well as collect the input from the last few weeks of
discussion. It's still a relatively small section, but we've done a
lot of talking and this is hard to get right.

These are the changes of note:

 - All of the TLS usage restrictions only apply to TLS 1.2 (TLS 1.3
won't permit all these things anyway), except the SNI requirement

 - Added explicit permission to fall back to HTTP/1.1
   -- There is a risk of a modest form of downgrade attack here that
I've identified

 - Added a recommendation to order cipher suites with preferred ones first

 - Prohibited the advertisement or selection of cipher suites that are
not known to conform to the cipher suite restrictions

 - Reduced the ECDHE security level to 112

 - A few editorial tweaks for clarity

Note:
I haven't taken Greg's suggestion to limit fallback to the case where
clients offer legacy suites for HTTP/1.1 servers.  As Ilari notes,
this doesn't help if you have independent TLS stacks that are using
suites that you don't understand.  Instead, this is a blanket
permission: if you see INADEQUATE_SECURITY, either from the server, or
you are forced to generate it, then you MAY fallback.

We could soften the prohibition on suites with unknown properties and
rely more on INADEQUATE_SECURITY to cover us.  My preference is to not
do that, because it creates a loophole, but I'd like input on that.

---

From: Brian Smith <[email-masked]>
Date: Fri, 10 Oct 2014 11:57:00 -0700

> won't permit all these things anyway), except the SNI requirement

I feel all these qualifiers of "TLS 1.2" are confusing because they
imply that the rules will be different for other versions of TLS. But,
older versions of TLS are not allowed and TLS 1.3 will have the same
rules anyway, so the "1.2" qualifiers seem unnecessary.

>    -- There is a risk of a modest form of downgrade attack here that

First of all, anything not forbidden is allowed already, so I don't
think that this needs to be explicitly stated even if it is allowed.
More importantly, I do not think that the HTTP/2 specification should
be endorsing this behavior--not only due to the increased risk of
downgrade attacks and increased complexity required to prevent them,
but also because this mechanism encourages implementations to do
things that are counterproductive to efficiency and performance (i.e.
counter to the whole reason for HTTP/2 to exist). Finally, if it isn't
a SHOULD or MUST level requirement then it doesn't promote improved
interoperability; in fact, I would say it decreases interoperability
because some servers might expect/require clients to actually do that
fallback, but many (AFAICT) won't.

>  - Reduced the ECDHE security level to 112

See my other message about the change to the 112 bit security level. I
suggested a better (IMO) alternative.

I also think that you should add a requirement that the client not
advertise HTTP/2 in its ALPN extension if ClientHello.client_version
is less than TLS 1.2. This would avoid the TLS version requirements
from being an interop issue at all.

Cheers,
Brian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 10 Oct 2014 21:19:43 +0200

> rules anyway, so the "1.2" qualifiers seem unnecessary.

The idea is that once TLS 1.3 is used, this spec can stop making 
requirements on top of what the TLS spec says. I believe that is a good 
thing.

> ...
Best regards, Julian

---

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

> rules anyway, so the "1.2" qualifiers seem unnecessary.

It’s important that these rules *do not* cover TLS 1.3, as the TLS specification is the appropriate place to define TLS rules, and as time goes on, the more out of sync and problematic 9.2.2 will become.

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

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 11 Oct 2014 08:26:42 +1100

> you are forced to generate it, then you MAY fallback.

So it does not address my concerns about a fragile handshake.     We need a
handshake that when presented ciphers/protocol combinations will always
successfully negotiate IFF there is a cipher/protocol pair that is
acceptable
to both endpoints - regardless of the presence of "surprise ciphers" that
may be understood differently by either endpoint.

Saying MAY retry is equivalent to say that the handshake MAY fail, even
when there are mutually acceptable protocol/cipher pairs.   It is also
saying that when this situation occurs, both end-points can point their
fingers at the other and say they MAY act to make the handshake work.

I fully understand that if we say MUST retry that there will be some impl's
that do not, just as there are going to be implementations that do not
fully enforce 9.2.2.   But by using the stronger MUST language the spec
will give help resolve these situations as it will indicate actions that an
endpoint MUST do to make the handshake succeed.

There is just no excuse for a newly designed protocol to have a fragile
handshake that relies on no-surprise ciphers to succeed.  As you have seen
from my multiple proposals, I don't really mind how a robust handshake is
achieve, just so long as we have one!

So still can't live with 9.2 and still wont be implementing it.

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: Martin Thomson <[email-masked]>
Date: Fri, 10 Oct 2014 14:44:02 -0700

Well, I tried.  My preference was for MUST NOT retry, and I think that
others are more firmly in favour of that.  You won't settle for
anything short of MUST retry, despite there being actual attacks that
enables.

I suggest that we've explored all avenues for consensus on this topic,
and will defer to Mark's judgment.

---

From: Rob Trace <[email-masked]>
Date: Fri, 10 Oct 2014 22:11:59 +0000

> I suggest that we've explored all avenues for consensus on this topic, and will defer to Mark's judgment.

Yes, I think we have identified the gap :-).  Even with all the discussion, we are still -1 on this proposal.  Our feedback isn't changed in that we believe the TLS section should be "MUST implement, SHOULD use."  

Thanks!!

-Rob

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Friday, October 10, 2014 2:44 PM
To: Greg Wilkins
Cc: HTTP Working Group
Subject: Re: Updated 9.2

Well, I tried.  My preference was for MUST NOT retry, and I think that others are more firmly in favour of that.  You won't settle for anything short of MUST retry, despite there being actual attacks that enables.

I suggest that we've explored all avenues for consensus on this topic, and will defer to Mark's judgment.

---

From: Greg Wilkins <[email-masked]>
Date: Sat, 11 Oct 2014 17:54:08 +1100

On 11 October 2014 08:44, Martin Thomson <[email-masked]> wrote:

> You won't settle for anything short of MUST retry,
>

Not true.

The only think I'm insisting on is that I MUST have a non-fragile
handshake. I don't really care how that is done:   Not supporting weak h1
ciphers; retrying for all h1 ciphers; retrying for weak h1 ciphers;
enhancing ALPN to communicate protocol cipher requirements;  having a fixed
white list of h1 weak ciphers.

In the environment that Jetty is implemented, any support of 9.2.2 is only
going to be approximate at best.  We mostly will ony have access to the
cipher name and will have to do some regex matching on it to implement
9.2.2 - but we will be subject to configuration and surprise ciphers.  Thus
I just know that in reality our 9.2.2 implementation will only be
approximate.   This would be OK and we would make the effort - IFF we had a
non-fragile handshake.

I am MUST NOT fail to handshake when there are mutually acceptable
cipher/protocol pairs available - even if 9.2.2 implementation is not
perfect.

Give me a robust handshake - any way you see fit, and then I will make a
best effort attempt to implement 9.2.2.  Which if ciphers develop the way
you expect may well be a good implementation of it.

regards

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 11 Oct 2014 11:53:34 +0300

> approximate.   This would be OK and we would make the effort - IFF we had a

AFAIK, 9.2.2 with proposed modifications plus server operating on
blacklist instead of whitelist is not fragile.

The client can operate on whitelist without causing fragility if it can
either fall back or not advertize any ciphers it doesn't think are acceptable.

The server can realistically do neither. Either it would need solution to
"variant ALPN" problem or disabling non h2-ciphers even for h1 (a non-
starter).

And if you have cipher names or even partial introspection capabilities
(not enough for full compliance) that blacklist might cover more than just
presently known TLS ciphers. E.g:

- Ban anything starting with 'TLS_RSA_WITH_' or TLS stack says has KX type
  of RSA.
- Ban anything containing '_WITH_NULL_' or TLS stack saying has cipher type
  of NULL.
- Ban anything containing '_WITH_RC4_128_' or TLS stack saying has cipher
  type of ARCFOUR_128.

-Ilari

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Oct 2014 00:52:02 +0300

On Oct 11, 2014, at 9:54 AM, Greg Wilkins <[email-masked]> wrote:

> 
> I am MUST NOT fail to handshake when there are mutually acceptable cipher/protocol pairs available - even if 9.2.2 implementation is not perfect.

That is problematic for writing servers in a modular way, separating the HTTP layer from the TLS layer.

The way the requirements are set in 9.2.2, if the client sends a ClientHello that says “will do AES-CBC or AES-GCM, for H1 or H2”, the TLS layer that is processing this message has two options:
 1. It can know internally that the combination of AES-CBC and H2 is invalid, and never choose that, or
 2. It can have no knowledge of this and sometimes choose that combination.

Now you can reduce the likelihood of that combination getting chosen by telling the TLS layer to prioritize AEAD ciphers. I don’t like that much, because priorities are better set by performance from all sufficiently secure ciphersuites.

#1 mixes layers in an ugly way. I’d rather not do it. If we’re left with #2, then there will be some cases where the TLS server picks a bad combination, and the HTTP part of the server should be able to deal with it. Otherwise we’re forcing the logic in 9.2.2 into the TLS layer.

So since the working group is not willing to drop the requirement altogether, I think the proposed wording is the right way to go.

Yoav

---

From: "Martin Nilsson" <[email-masked]>
Date: Sun, 12 Oct 2014 00:00:37 +0200

> won't permit all these things anyway), except the SNI requirement

The fact that it is not possible to connect to domain-less servers with  
secure HTTP/2 is hidden pretty deep, and will probably come as a surprise  
to some people. This is not new, and I'm only worrying on behalf of other  
people, so perhaps this is a non-issue.

/Martin Nilsson

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

---

From: Greg Wilkins <[email-masked]>
Date: Sun, 12 Oct 2014 09:16:14 +1100

> blacklist instead of whitelist is not fragile.

So long as the client uses a whitelist and so long as the server operates on
a black list and so long as the server can actually influence cipher
selection
and so long as it bans any cipher matching the 3 patterns you provided
and so long as cipher names never differ from those patterns and so long as
no additional patterns are configured.

I think you just defined fragile.

regards