LWN: Comments on "Should the IETF ship or skip HTTP 2.0?"

Should the IETF ship or skip HTTP 2.0?

nybble41 — Fri, 06 Jun 2014 22:20:48 +0000

Oh, sure, "easy". Until you read sections 5.1.2 regarding canonical host names, and 5.3.5 (which I think "job" was referring to) regarding the ever-varying list of "public prefixes" requiring special consideration--without which any random example.com could register a cookie for "com." and have it scoped over nearly all commercial websites.

Should the IETF ship or skip HTTP 2.0?

job — Fri, 06 Jun 2014 21:40:20 +0000

I always found it slightly worrying that out of all the things that could be improved with HTTP, they chose this. As if we didn't have enough protocols overlaid on HTTP, now we want to run TCP on top of it as well!

(By the way, I'm far from convinced that stream protocols along the lines of SCTP isn't a better way to achieve stream multiplexing. Sure, there would be compatibility problems, but the endpoint could choose to use it only when available and let the problems sort themselves out over the next decade. It's not as if there isn't firewall issues with SPDY.)

The most glaring omission with HTTP must be session management. This has been bolted on with cookies, but that does not work very well in practice. It makes it very difficult to know when you can serve cached documents, since cookies can carry all sorts of meanings. It's security semantics is all over the place and they can leak a thousand ways -- not to mention the gouge-your-eyes-out rules on which domains get to use them. Nobody uses HTTP authentication for public web sites simply because there is no login session management. That is why we can't have nice things such as SRP. Instead we send passwords back and forth over the wire. In 2014.

So there's plenty work to do that could improve security and reliability in obvious ways. But instead we get ... multiplexing and compression? That may shave off a few bytes here and there? That's close to useless. Most sites could with a single run of pngcrush do an order of magnitude better. Even Google, who supposedly runs a tight ship, could shave off thousands of bytes on every home page request of they structured their markup a bit tighter. But they don't. Because it doesn't matter.

Should the IETF ship or skip HTTP 2.0?

Cyberax — Fri, 06 Jun 2014 21:20:00 +0000

Whut?

Cookie scoping is easy: http://tools.ietf.org/html/rfc6265#section-4

Should the IETF ship or skip HTTP 2.0?

job — Fri, 06 Jun 2014 21:15:49 +0000

Dear god no, don't put "easily" in the same sentence as cookie scoping. Have you actually looked at the ghastly ad-hoc spaghetti that govern that? It involves hard coding pretty much all the TLDs, and that's just the beginning of it.

Should the IETF ship or skip HTTP 2.0?

Cyberax — Thu, 05 Jun 2014 14:25:52 +0000

> No, because if one gets intercepted, that cookie is good for years.
So? If someone intercepts your session ID they'd still be able to access your data for the duration of the session.

> Use RequestPolicy and don't let J. Random Website force your browser to communicate with any other site. Saves bandwidth too.
You are free to do that with cookies.

Should the IETF ship or skip HTTP 2.0?

mathstuf — Thu, 05 Jun 2014 11:54:52 +0000

> And lastly, nobody stops you from deleting cookies every day or restricting them in any way.

No, because if one gets intercepted, that cookie is good for years.

> For example, if I place an image from http://google.com/someanalytics on my page and you have a session ID for google.com domain then you'd still be tracked.

Use RequestPolicy and don't let J. Random Website force your browser to communicate with any other site. Saves bandwidth too.

Getting rid of bad design

Wol — Thu, 05 Jun 2014 10:42:17 +0000

Reading tfa, I think there is a good reason for shipping it.

But before you do

1) Add the requirement that an http/2 compliant browser/server may not *initiate* the use of deprecated features, and

2) All those naff features? Deprecate them!

Not quite sure how you get round deprecated features with no alternative, maybe mark them for future deprecation, and introduce 2.1, 2.2 etc as replacements get invented.

But that way, you can easily start designing http/3, knowing that all those features will be disappearing.

Cheers,
Wol

Should the IETF ship or skip HTTP 2.0?

Cyberax — Wed, 04 Jun 2014 20:58:02 +0000

Won't help at all. For example, if I place an image from http://google.com/someanalytics on my page and you have a session ID for google.com domain then you'd still be tracked.

And of course, I personally _want_ lots of my sessions to last more than 1 day or week.

And lastly, nobody stops you from deleting cookies every day or restricting them in any way.

Should the IETF ship or skip HTTP 2.0?

Cyberax — Wed, 04 Jun 2014 20:46:07 +0000

If you CAN offer how to do it, then feel free to offer your ideas to IETF WG. They haven't found a way to do header compression securely with zlib.

Should the IETF ship or skip HTTP 2.0?

josh — Wed, 04 Jun 2014 20:05:13 +0000

You definitely don't want to change the encoding; it should remain deflate-compatible. Just provide ways to control zlib compression to meet the security requirements.

Should the IETF ship or skip HTTP 2.0?

raven667 — Wed, 04 Jun 2014 19:50:07 +0000

But if you modify it, is it still zlib anymore? You might have a custom encoding that can use stock zlib to decode and remain compatible but if you change the decoding then you still have effectively built a custom system and will have the maintenance costs of a custom system, not the costs of using a common library.

Should the IETF ship or skip HTTP 2.0?

josh — Wed, 04 Jun 2014 19:20:44 +0000

> They actually tried it with ZLIB with a prepopulated dictionary. Still doesn't work, because compression leaks data.

That's fixable, as evidenced by HPACK. An unmodified zlib leaks information; a version of zlib modified to support tradeoffs between security and compression need not leak information.

Should the IETF ship or skip HTTP 2.0?

Cyberax — Wed, 04 Jun 2014 17:51:06 +0000

They actually tried it with ZLIB with a prepopulated dictionary. Still doesn't work, because compression leaks data.

And if you think about it, pretty much ALL headers are security-sensitive.

Should the IETF ship or skip HTTP 2.0?

josh — Wed, 04 Jun 2014 17:14:51 +0000

HTTP 2 seems to have suffered from the second system effect. Picking up SPDY and declaring it HTTP 1.2 would have helped greatly; instead, this effort seems to have tried to solve every problem with HTTP simultaneously rather than establishing an incremental standard that solves a common subset of clear problems.

Inventing a new compression algorithm for HTTP headers (HPACK), rather than using an off-the-shelf compression algorithm (like zlib) seems like a good example of that. HPACK has the stated rationale of avoiding attacks like CRIME, but rather than add controls to existing compression algorithms to avoid attacks (such as not compressing sensitive headers, or otherwise trading off compression for hardening), it invents a new compression format. That compression format addresses some of *today's* problems (though apparently not even all of those), but when (not if) the next such problem appears, we'll just get stuck with HPACK plus modifications and mitigations rather than zlib plus modifications and mitigations.

Should the IETF ship or skip HTTP 2.0?

nim-nim — Wed, 04 Jun 2014 06:59:40 +0000

Scoping by fqnd and browser session or fqdn + 1 day/week max.

That would be sufficient to limit abuses.

Should the IETF ship or skip HTTP 2.0?

Cyberax — Tue, 03 Jun 2014 18:04:26 +0000

Most cookies are used to store session IDs. For example, the Evil Google Cookie only stores a longish session ID.

Next, currently cookies are easily scoped - by their domain. How do you propose to scope session IDs?

Should the IETF ship or skip HTTP 2.0?

nim-nim — Tue, 03 Jun 2014 18:04:15 +0000

All the proposals have been shot down in the work group before getting the chance to be fleshed out. You can find them in the archives, with the constant refusal of the group head to open this subject.

Should the IETF ship or skip HTTP 2.0?

nim-nim — Tue, 03 Jun 2014 18:00:46 +0000

A session ID pushes data persistence server side and can be severely scoped by the browser instead of the way cookies make mass tracking dirt cheap (save anything you want in the cookie, allow everything to read it, no data costs, no need to synchronise servers, your target is doing all the work for you.

What changed in the past years is not the ability to spy on people but that's it's so cheap you can even set it up just in case you need it later. Making it a little harder would go a long way to limit opportunistic abuses

Should the IETF ship or skip HTTP 2.0?

intgr — Tue, 03 Jun 2014 17:05:56 +0000

> IETF refused to open the cookie issue despite it being trivial to solve (don't save anything client side, provide a session id).

Doesn't sound trivial to me. Is there a more detailed proposal for this?

Should the IETF ship or skip HTTP 2.0?

Cyberax — Tue, 03 Jun 2014 10:07:58 +0000

How a session ID is not a cookie? It'll have all the problems of cookies if you want it to have equivalent functionality.

Should the IETF ship or skip HTTP 2.0?

nim-nim — Tue, 03 Jun 2014 09:58:25 +0000

Well, the analysis is rather short and does not really why people are not satisfied with http/2

As noted by phk http/2 is a rather unbalanced protocol that shows its Google roots, and in the name of expediency the IETF refused to fix a lot of its problems:

1. it gained approval by some privacy groups by enshrining TLS, but without real analysis of http privacy emplications. As a result it only secures Google/facebook… data mining

2. it is a "no new features" protocol except that it includes server push (which changes completely http security)

3. on the other hand the IETF refused to open the cookie issue despite it being trivial to solve (don't save anything client side, provide a session id). The ietf argued a cookie-less protocol would see no adoption despite contrary evidence (the same people claimed UE's requirement to tell users about cookies could not be implemented)

Should the IETF ship or skip HTTP 2.0?

marcH — Sun, 01 Jun 2014 22:10:19 +0000

> This sounds like the average manager comparing functional qualities with planning stress.

Indeed - a standardization body is the last place where I expected to hear this. A standard is not a product and products never need to wait for the final, correct version of a standard.

Just print something and call it HTTP 1.99-beta if that makes some people happier.

Please admit insecurity

ballombe — Fri, 30 May 2014 18:59:44 +0000

I offer this link to a post of Poul-Henning Kamp in the same thread
<http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJ...>

Please admit insecurity

Max.Hyre — Fri, 30 May 2014 16:56:05 +0000

Why should we get another specification with security holes built in?

“Rough concensus and running code” got the Internet underway, but the world’s changed a lot since then. Private information transfer is under attack from groups as diverse as the NSA/GCHQ, the RIAA/MPAA, and ISPs hungry for more profit, and every shortcoming, misunderstanding, or misimplementation offers another attack vector for them.

Each of Greg Wilkins's four problems introduces another opportunity for such misfeatures (or even seems to guarantee them in the cases of HPACK and headers with data). The IETF now asserts that pervasive monitoring is an attack.

Heaven knows I understand the pain of having worked for six years without a release, but how can they approve a standard that makes things worse?

Should the IETF ship or skip HTTP 2.0?

jezuch — Fri, 30 May 2014 07:54:05 +0000

So... are advantages of HTTP/2 worth it? Would we be really worse-off if we dropped it? Yes, there are some nice things in there but I don't think I've seen anything that would clearly say "yes" to these questions...

Should the IETF ship or skip HTTP 2.0?

gren — Fri, 30 May 2014 07:06:09 +0000

Thanks. I'm glad to see some analysis of what lead up to the "please admit defeat" message and the issues it was complaining about.

Should the IETF ship or skip HTTP 2.0?

Asebe8zu — Fri, 30 May 2014 05:25:27 +0000

..."the best we can do is make everyone more-or-less equally dissatisfied. Right now, I’m hearing dissatisfaction from you and others about spec complexity at the same time I’m hearing dissatisfaction from others about schedule slips..."

This sounds like the average manager comparing functional qualities with planning stress.