W3C home > Mailing lists > Public > www-tag@w3.org > February 2015

Re: Considering the pressure to turn HTTPS into a three-party protocol

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Sun, 15 Feb 2015 21:44:15 -0500
Message-ID: <54E1597F.70506@arcanedomain.com>
To: Ryan Sleevi <sleevi@google.com>, Mark Nottingham <mnot@mnot.net>
CC: "www-tag@w3.org List" <www-tag@w3.org>
Among the reasons that I think this is in scope for the TAG/W3C as well as 
IETF is the role that Certs and authentication play in the mapping of 
https-scheme URIs to resources. Reasonable people may disagree on what that 
role is, but clearly there is at least some implicit expectation, and 
arguably an explicit expectation created by pertinent specifications, that 
resolution of https-scheme URIs will involve a check against the 
certificate served by the origin server.

Maybe that's true or maybe not, but I think it's very much in scope for the 
TAG to clarify and if appropriate to make recommendations.


On 2/15/2015 8:54 PM, Ryan Sleevi wrote:
> On Sun, Feb 15, 2015 at 5:25 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> My point is that in the currently deployed Web, users are allowing "bad guys" -- even if well-intentioned ones -- onto their systems without understanding what they're doing. While this is always going to be the case (e.g., downloaded binaries), we have what amount to undocumented features in the Web platform which encourage it.
> Does this mean that the next activity for the TAG is to issue a draft
> finding on antivirus solutions, how they're implemented, and what they
> communicate to the user?
> I don't mean to be snarky, but merely to highlight that this is a
> problem regardless of whether you're talking CA certificates, split
> browsers, extensions, browser helpers, performance tuners, registry
> cleaners, ram doublers, free games, desktop buddies, or any number of
> the hundreds of other things people will download and run on their
> machines. Are we to suggest that these are all now undocumented
> features of the Web platform, simply because they may affect how the
> users' machine operates (and therefore, accesses the Web?)
> I would strongly disagree that this is, by any means, some
> "undocumented feature of the Web platform". Even if we were to accept
> that as true (a mistake, I believe), then its very nature should
> suggest that it's not the purview of the W3C, but of the IETF - land
> of protocols and best practices and deployments. After all, why
> shouldn't the behaviour of a TLS client be discussed in the same fora
> where TLS implementation is discussed? Why wouldn't the discussion of
> HTTP proxies be better discussed where HTTP proxies are defined - such
> as HTTPbis?
> I appreciate the consideration to "think about the users," but I
> disagree with both the premise and the suggested result. Your concern
> that this is a "browser problem" further disturbs me for the scope.
> Does this mean to suggest that the W3C TAG will have finding on how
> "enterprise managable" browsers are, with a similar opinion?
>> I don't want to get expectations (or your fears) too inflamed -- this may just end up being an education campaign (perhaps with EFF?) along with some discussions around how there can be better alignment between certain features of browsers, along with better documentation around them.
> And here again, I would suggest, the W3C is the wrong forum for this.
> If you wish to discuss Best Community Practice for HTTP
> intermediaries, why not go where HTTP intermediaries are defined - the
> HTTP WG? If you wish to discuss ways in which the Web PKI operates in
> practice, why not go discuss in the WebPKI Ops WG? If you wish to
> discuss whether TLS with server-only authentication should be expected
> to provide End to End security, why not discuss in the TLS WG? If you
> wish to discuss how TLS is used in applications, why not discuss in
> the UTA (Using TLS in Applications) WG?
Received on Monday, 16 February 2015 02:44:37 UTC

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