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

Re: SSL/TLS everywhere fail

From: Poul-Henning Kamp <phk@phk.freebsd.dk>
Date: Mon, 07 Dec 2015 12:13:11 +0000
To: Cory Benfield <cory@lukasa.co.uk>
cc: Jacob Appelbaum <jacob@appelbaum.net>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
Message-ID: <71889.1449490391@critter.freebsd.dk>
In message <AD5923A5-875D-4A3B-AFFF-26CE042934FC@lukasa.co.uk>, Cory Benfield writes:

>> I am not sure I understand why you consider that an "absurd flaw"
>> and I have not been able to find any mail-discussion where such
>> a critique is raised.
>> Can you summarize the argument ?

Thanks for the summary.

I find it a bit harsh to say that the proposed header/signature
format has an "absurd flaw" when the flaw complained about is 
really "key distribution is hard".

Yes, key-distribution can be hard, but that is a separate issue.

>As a result, I consider it extremely important that any implementation 
>we have either be TOFU and have a normative requirement to cache that 
>key indefinitely, or that it use some out-of-band key distribution 
>mechanism. Otherwise, all an attacker needs to do is sit on the 
>connection and replace both the body *and* the key: a relatively trivial 
>thing to do.

Again, this is the general key-distribution problem which have no
"ideal" and often not even "adequate" solutions.

But there are large swatches of the HTTP traffic where there are
perfectly good and workable key-distribution mechanisms, and holding
them up, waiting for a solution to an unsolveable problem makes no

To take one example:  API and IoS HTTP traffic almost always have
the ability to implement PSK, and key distribution doesn't get
any better than that.

There are also a lot of creative ways that key-distribution can
be boot-strapped in the browser-centric HTTP universe.

For instance I could open a HTTPS to a newspaper, and one of the
things I get back is the instruction:  "When you pick up our stuff
from the 3rd party CDN, the content must be signed with this key".

That could put integrity around an awfull lot of content which
simply doesn't need TLS because it is 100% public, with the
huge added benefit that the CDN's do need access to keys.

Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.
Received on Monday, 7 December 2015 12:13:39 UTC

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