[tahoe-dev] Bringing Tahoe ideas to HTTP

[Fuzzy Hoodie-Monster]

On Wed, Sep 2, 2009 at 8:27 AM, Zooko Wilcox-O'Hearn<zooko at zooko.com> wrote:

> Brian's proposal to add end-to-end authentication to the Web doesn't
> require putting secret information into the URLs.  The proposal to
> add end-to-end confidentiality to the Web does.  The end-to-end
> authentication is also backwards-compatible with the existing web
> agents -- they all ignore the authentication information in the URL
> fragment and go ahead and accept the document without authenticating
> it.  (I suppose there could be a problem with web apps that are
> already using the URL fragment for something else.)  The proposal to
> add end-to-end confidentiality is not backwards-compatible.  If you
> were to publish a file with that feature, then nobody would be able
> to read it with an old web browser or an old version of wget, etc.

I don't want to argue about what "end-to-end" "really" means. But as a
practical matter, proposals more fine-grained ("endy") than TLS have
(in some key cases, at least) shown to be unusable ("literally DOZENS
of people use PGP") or worse than nothing for raisins of complexity
and security (XML digital signatures).

> Thanks for bringing this "HTTPA" proposal to my attention!  This
> would give you an integrity guarantee that the whatevs.html page that
> you get was indeed the one that the author of this page intended.

I think of it as an optimization: HTTPS already gives you such a
guarantee, modulo the ferocity of one's e2e ideology; HTTPA would let
you get away with using HTTPS only for the enclosing page. And you'd
still lose confidentiality on the authenticated-only components (which
is often ok).

> But how would you share the whatevs.html page with a friend of yours
> in such a way that your friend would get an integrity guarantee that
> he was looking at the page that you intended?  I guess you would have
> to create an HTML page and set the "hash" attribute and then, um,
> send that HTML page (not a link to it) directly to your friend.

Again, I regard TLS' provision of server authentication as "good
enough", for now at least. I definitely don't regard CAs or browsers'
handling of certificates or browsers' UI as good enough. I advocate
fixing the weakest link in the chain, and currently that's user
interface/user experience/communication to the user. Once we figure
out how to explain to users who they are or might be talking to and
how certain we are of that -- again, see OTR for hints -- THEN we can
move on to the next problem.

I suspect the next problem will probably not be "How can we get more
endy". I've spent an inordinate amount of time trying to convince web
application developers to use HTTPS instead of HTTP for sensitive
applications. Turning on HTTPS is the easiest thing, and the minimal
thing, that developers could do to begin to meet any security goal.
(Sometimes I like to point out that they are in gross violation of
their privacy policy. That gets the lawyers wiggling, at least. Good
times!)

Brian's proposal would be more complex and require more interaction
between more people (protocol droids, client and server implementors,
application developers, users, et al.). However, I get a lot of
pushback even on HTTPS, the simplest possible configuration change.
The objections are almost always founded on incorrect assumptions
("HTTP provides some security", "HTTPS is too slow"), but there you
have it.