W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: Privacy and its costs (was: Re: Mandatory encryption)

From: Nicolas Mailhot <nicolas.mailhot@laposte.net>
Date: Thu, 19 Jul 2012 17:49:15 +0200
Message-ID: <2c3ef6c0554841b83705edb081a855fa.squirrel@arekh.dyndns.org>
To: "Henry Story" <henry.story@bblfish.net>
Cc: "Tim Bray" <tbray@textuality.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Martin J. Dürst" <duerst@it.aoyama.ac.jp>

> I think in the case of Ongoing privacy is not in fact important. But
> security is!

I think that in many cases, what matters is not 'have I got a direct
opaque un-spoofable link to the web site' (that TLS gives you) but 'is the
content I receive the same a trusted entity published' (non-tampering)

You have this problem with intermediaries but also without intermediaries

For example, all the mirroring sites that perform a service for free of
live by slapping ads around convenient ways to download content produced
by others.

What matters when someone goes to downloads.com, is not that he is talking
to downloads.com itself, but that the binary payload downloaded was
actually released by the editor downloads.com labels it with.

If HTTP/2 includes a command that basically means 'give me the signed
digest associated with URL X or Y':
1. user agents can check if intermediaries didn't mess with the relayed
2. user agents can check if the content they received over a supposedly
secure link was not tampered before transmission, if the web site is not
the original producer of the content (mirrors just have to mirror the
original signature in addition to the content itself). Secure link ≠
secure content

This is something TLS itself will never give you, the TLS trust model does
not work at all in any relaying situation (either direct relay with
proxies and other intermediaries, or deferred rely in the mirror case)

So you solve two problems in one go and the protocol changes are useful
even in proxy-less environments

Or am I missing something?

Nicolas Mailhot
Received on Thursday, 19 July 2012 15:50:09 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:03 UTC