W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: SSL/TLS everywhere fail

From: Cory Benfield <cory@lukasa.co.uk>
Date: Mon, 7 Dec 2015 08:31:29 +0000
Cc: Jacob Appelbaum <jacob@appelbaum.net>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-Id: <51A9584D-0F29-484A-AAC5-75C46D35658F@lukasa.co.uk>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

> On 6 Dec 2015, at 17:32, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> The biggest current protocol deficiency is that HTTP offers no means
> to check integrity.
> That could be done with a simple HTTP header and a thumbs-up icon
> in the address-bar, and it wouldn't cost TLS startup overhead and
> wouldn't impact the cachebility of the high volume traffic.
> To the extent people paid attention to the thumb-up icon[2] it would
> instantly prevent ad-injection, make a very large swath of simple
> criminal activity impossible, and expose complex criminal activity
> to a new range of legal risks (forging documents etc.)
> Such calibrated measures, no matter their good cost/benefit, are
> of course incompatible with the IETF's "all-out-war" attitude which
> Stephen detailed in his email:  Integrity is routinely, as you just
> did above, taken hostage for the "TLS everywhere" agenda.

Would you like to elaborate on how this would be done? Hashing the body content? Because an attacker can rewrite the header as well. Hashing the headers? Well, again, the attacker can rewrite those and recompute a hash on the entire thing. Signing the body? How does the client obtain the public key they use to verify the signature?

I ask these questions only because you used the word “simple”. The header itself (as in, the bytes on the wire) may be simple, but the technological underpinnings of this approach are *not* simple, at least as far as I can see. The best we have right now is a current I-D that aims to address exactly this, draft-thomson-http-content-signature[0], and that draft suffers from the absurd flaw that the signing public key is transmitted in unauthenticated cleartext right alongside the signature itself. The draft does save itself by allowing the key to be provisioned by other means, but omits to suggest what that would be.

As you have correctly identified in the past, Poul-Henning, establishing trust for crypto keys is tricky. You have objected to the CA system in what I would call “strong” language. Fine. Tell me how you want to do it for integrity checking of HTTP messages.

I am desperate for a good body-encryption draft, and I am desperate for a good integrity draft. You suggested in the above text that such a thing would be straightforward to build (*not* easy, straightforward). Good! Tell me how it should work, and I’ll even write the I-D for you, out of respect to your time constraints. I’d love to see this exist.


[0]: https://tools.ietf.org/html/draft-thomson-http-content-signature-00

Received on Monday, 7 December 2015 08:32:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC