W3C home > Mailing lists > Public > www-tag@w3.org > December 2014

Re: Fwd (TAG): Draft finding - "Transitioning the Web to HTTPS"

From: Eric J. Bowman <eric@bisonsystems.net>
Date: Tue, 30 Dec 2014 18:56:01 -0700
To: Chris Palmer <palmer@google.com>
Cc: Marc Fawzi <marc.fawzi@gmail.com>, "henry.story@bblfish.net" <henry.story@bblfish.net>, Nick Doty <npdoty@w3.org>, David Singer <singer@apple.com>, TAG List <www-tag@w3.org>, "public-privacy (W3C mailing list)" <public-privacy@w3.org>
Message-Id: <20141230185601.d9298b1c20a4562711eaae58@bisonsystems.net>
Chris Palmer wrote:
> 
> HTTPS — TLS + HTTP — is what we have. It's widely supported, and
> widely deployed. It's not perfect, but it's what we have, and we are
> improving it (such as by starting to prefer and then require AEAD
> ciphersuites and ciphersuites with forward secrecy).
> 
> The Web PKI, including its trusted-third party introducer model, is
> again widely supported and widely deployed. It's not perfect, but it's
> what we have, and we are working on mitigating its known weaknesses
> (such as with Certificate Transparency).
> 

But this isn't all that we have, and nobody seems to have discussed
Authentication headers as an alternative to most of the problems we're
trying to jerry-rig HTTPS to solve.

> 
> At this point, HTTPS and the Web PKI are the state of the art. They
> are better than any proposed alternatives we have heard of, both in
> theory and in practice, and are in widespread use now. They are a huge
> a improvement over unauthenticated, plaintext, non-integrity-protected
> HTTP.
> 

I'd say better than any proposed alternatives *discussed* while
overlooking HTTP Auth -- which is also an improvement over same, and
certainly state-of-the-art compared to cookies. Plus, HTTPS doesn't
protect the integrity of content, there's a mechanism missing there --
Content-Md5 may have failed, but I don't see where it disproved the
concept of an integrity-check header, and I don't see where security or
privacy can be achieved on the Web without integrity checks, HTTP or
HTTPS.

Widespread deployment/use of a solution isn't a winning argument with
me, if that solution doesn't solve the problem, only kicking the can
further down the road. Whereas discussing / trying to engineer an
actual solution may lead to methods (HTTP Auth) which have also been
widely implemented, and may actually solve the problem without
requiring TLS.

Proper implementation of a solution to privacy issues, is best left
until *after* a proper solution has been found. Not just anointing the
best flawed solution because it's easier than solving the problem, and
implementing it *seems* like taking action.

>
> At this point, the burden of proof that a viable alternative exists is
> not on W3C TAG. Furthermore, waiting 10+ years for a viable
> alternative to be designed, widely deployed and widely adopted is not
> a serious option.
>

Or, wouldn't be on the TAG if the discussions hadn't been lazer-focused
on anointing ubiquitous HTTPS. Alternatives that were never discussed,
were also never falsified. So the burden of proof isn't shifted to me
for pointing out the absence of serious discussions of alternatives,
means alternatives should be discussed. If that alternative is based on
HTTP Auth, then there's no 10-year wait for adoption/deployment.

-Eric
Received on Wednesday, 31 December 2014 01:56:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:08 UTC