Subject: null ciphers in 9.2.2

From: Martin Thomson <[email-masked]>
Date: Fri, 26 Sep 2014 16:49:17 +0100

As a clarification, I think that we need to be sure to say that the
null cipher is not permitted.

Technically, the null cipher is a stream cipher, but this isn't made
explicit in the draft.

I'm going to add this to the chain of changes I have for 9.2.2, since
I hate managing conflicts.  So it won't hit the main spec until we
resolve that issue.

---

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

My comments in the other thread are very much about IF we are to restrict
ciphers can we at least do so in a non fragile way.

My response here is do we really really have to have 9.2.2?

Enforcing strong ciphers is targeted at trying to make main stream
deployments better, but a whole bunch of niche use-cases are going to be
innocent bystanders that are outlawed by 9.2.2.

For example, using null ciphers for debugging purposes is now a casualty of
9.2.2.  I'm sure there are other niche use-cases that will probably be
taken out.

I totally get why you want to have 9.2.2, but the application protocol us
just the wrong place to try to do it and I think we are yet to have an idea
of how deep the unintended consequences will be.

regards

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Sep 2014 09:45:20 -0700

On 30 September 2014 02:22, FOSSATI, Thomas (Thomas)
<[email-masked]> wrote:
> A NULL cipher is a secure option if you just want authentication and integrity.

That is not the guarantee that the https:// scheme demands.  It also
requires confidentiality.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Sep 2014 13:34:59 -0700

On 30 September 2014 13:25, FOSSATI, Thomas (Thomas)
<[email-masked]> wrote:
> true for https resources.  But I can't find any explicit reference to https in 9.2 (and subsections), therefore I was inferring that those requirements also apply to opp-sec use of TLS?

Would you like to make an argument for integrity-only for
opportunistic security?  I can't imagine any argument that I'd find
compelling, but am always willing to be surprised.

---

From: MISSY LAWSON <[email-masked]>
Date: Tue, 30 Sep 2014 15:43:56 -0500

Sent from my iPhone

> On Sep 30, 2014, at 3:34 PM, Martin Thomson <[email-masked]> wrote:
>

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Oct 2014 09:36:08 +1000

> compelling, but am always willing to be surprised.

I've been writing a HTTP server for 20 years and in that time I have
continued to be surprised and then surprised again by the incredible varied
and lateral uses that the protocol has been put to in all manner of
situations.

Just because we cannot imagine why something would be done today does not
mean there will not be a use for it tomorrow.

Sure strong encryption is a good thing to have of today's public networks,
but there may be all manner of surprising deployment modes that come out in
the future that wish to use TLS, but not with a 9.2.2 compliant cipher.

9.2.2 attempts to avoid surprises by suppressing innovation.  It fails to
recognise that some surprises are pleasant surprises.

Let's not limit the usage of this protocol by the limit of our imaginations.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Oct 2014 00:46:05 +0100

> Let's not limit the usage of this protocol by the limit of our imaginations.

Sorry to rain on the rhetorical games, but no, 9.2.2 (perhaps
a little clumsily) just seems to me to try reflect where TLS1.3
is heading towards. Having HTTP/2.0 and TLS1.3 heading in the
same direction seems eminently reasonable to me at least. I'm
sure that could be achieved in other ways, but that kind of
consistency seems to me to be a laudable goal for both working
groups, both specification and both sets of implementations
and deployments.

S.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Sep 2014 16:54:00 -0700

> groups, both specification and both sets of implementations

Yep, that is the intent precisely.  None of the choices reflected
there, with the possible exception of the MUST implement cipher suite,
were made by this working group, they are just copying choices made in
TLS.

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Oct 2014 10:10:12 +1000

Great, so we copy/paste TLS1.3 requirements into our draft.  That makes us
good for how many decades?  When HTTP/1.1 was specified TLS was at version
1.0.  If it had hard coded TLS1.1 requirements then we would not be running
h1 over TLS1.2 today.

I am not saying that these are not good restrictions to have on the
majority use-case for h2.  I'm just saying that they are restrictions that
are being developed elsewhere and we have no need to become the enforcer of
them, nor do they generally apply to all our current and future possible
use-cases.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 01 Oct 2014 01:22:18 +0100

On 01/10/14 01:10, Greg Wilkins wrote:
> majority use-case for h2.  

While I didn't memorise all of the mails commenting on this short
section of the draft, I do think I saw some claims that these were
"not good."

> I'm just saying that they are restrictions that

Hmmm. If you have specific arguments against those choices then I
suggest you should raise those on the TLS WG list. Its pretty likely
that TLS code will sooner or later reflect what the TLS1.3 spec
mandates after all so if you don't like the meat of the selections
that's the place to make your case most effectively probably.

If you have an editorial problem then suggesting specification text
would seem better than feeling suppressed or being limited in
one's imagination. (Sorry, couldn't resist:-)

If you have a substantive suggestion for how to better couple or
decouple the two specifications, then again, suggesting text would
be the way I think. (And the proper (de)coupling of related specs
is an ongoing real problem that I doubt we'll solve in general
but that can often be improved upon in specific cases.)

S.

PS: Apologies if text was already suggested recently for this, I
really didn't have time to read the many thousands of lines of
mail on the couple of dozen lines of 9.2.2;-)

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 1 Oct 2014 10:48:29 +1000

> mail on the couple of dozen lines of 9.2.2;-)

If you have not read my contributions, then please do not (incorrectly)
paraphrase the suggestions that I have made in this WG.

> be the way I think.

As it has been pointed out before, the text in our charter perfectly
describes how to decouple the two specifications:

*Note that it is expected that the Working Group will work with the TLS
working group to define how the protocol is used with the TLS Protocol; any
revisions to RFC 2818 will be done in the TLS working group.*

Thus I would substantively suggest that  HTTP over TLS should be specified
by a revision of "RFC2818 HTTP Over TLS"

---

From: Jason Greene <[email-masked]>
Date: Tue, 30 Sep 2014 22:05:24 -0500

On Sep 30, 2014, at 6:46 PM, Stephen Farrell <[email-masked]> wrote:

> is heading towards.

Except that TLS 1.3 is designed to be backwards compatible with TLS 1.2, including the ability to use less modern ciphers, which will most definitely be used with H1 clients. HTTP/2 is adding restrictions above and beyond what TLS 1.3 requires, and placing addition restrictions on TLS 1.2.

If HTTP/2 simply wanted to reflect where TLS 1.3 was heading towards, it could accomplish that by requiring the capabilities of 1.3, and leaving out the social hack.

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

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Sep 2014 20:09:28 -0700

> If HTTP/2 simply wanted to reflect where TLS 1.3 was heading towards, it could accomplish that by requiring the capabilities of 1.3, and leaving out the social hack.

I don't know how to interpret that statement.  We are reflecting where
TLS 1.3 is heading.  That means that I don't know what the "social
hack" you are refer to is.

---

From: Jason Greene <[email-masked]>
Date: Tue, 30 Sep 2014 22:15:00 -0500

> hack" you are refer to is.

A TLS 1.3 stack will accept a TLS 1.2 client using a cipher which a compliant HTTP/2 stack will then reject. 
--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

---

From: Jason Greene <[email-masked]>
Date: Tue, 30 Sep 2014 22:15:00 -0500

---

From: Martin Thomson <[email-masked]>
Date: Tue, 30 Sep 2014 20:27:44 -0700

> A TLS 1.3 stack will accept a TLS 1.2 client using a cipher which a compliant HTTP/2 stack will then reject.

How is that possible?  I'm not saying that my understanding is
perfect, but I believe that's impossible.

---

From: Jason Greene <[email-masked]>
Date: Tue, 30 Sep 2014 23:38:09 -0500

> perfect, but I believe that's impossible.

So the current TLS 1.3 draft allows a TLS 1.3 server to accept connections for anything from SSL 3 to 1.3. A TLS 1.2 client can specify a block cipher like AES256-CBC, and that will be accepted by the TLS stack (unless of course the TLS implementation has been operationally configured not to allow it). Such ciphers aren’t bad, they just aren’t state of the art, and are accepted by major websites/servers right now. They will likely continue to be supported as well since sites wish to remain compatible with legacy devices and software.

If the client uses HTTP/1.1 and TLS 1.2 talking to a TLS 1.3 server, using CBC it will all work fine. However, if the client uses HTTP/2, and CBC ends up getting negotiated, then the server needs to reject with INADEQUATE_SECURITY. So HTTP/2 is asserting additional restrictions beyond what a TLS 1.3 stack would natively do. Since both HTTP/1.1 and HTTP/2 share the same port, a dual h1/h2 stack will be forced to do fiddly things to allow ciphers from H1 that it will disallow on H2.