- 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>
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