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

Re: Re-org of web-https

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Mon, 12 Jan 2015 17:36:51 +0200
Message-ID: <CAJQvAucZvfkud_nbxQN2107osj0C3smmhc6AdxgmG3NE+AV5-Q@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Public TAG List <www-tag@w3.org>
On Sun, Jan 11, 2015 at 9:22 PM, Mark Nottingham <mnot@mnot.net> wrote:
>   https://w3ctag.github.io/web-https/

Again, great to see progress on this. A couple of complaints:

1:

I'm pretty disappointed by the text under "Facilitating Shared
Caching". It gets to a good start with:
> Adopting "https://" has the side effect of disallowing shared HTTP caching
> [RFC7234]. Shared caching has a limited role on the Web today; many high
> traffic sites either discourage caching with metadata, or disallow it by already
> using "https://".

But then this follows:
> However, it is still useful, and in some cases (in particular, access from limited
> networks), highly desirable; in some cases, it might be so desirable that networks
> require users to accept TLS Man-in-the-Middle. Therefore, we encourage
> exploration of alternative mechanisms that preserve security more robustly,
> such as certain uses of Subresource Integrity [SRI].

This doesn't seem to match what you said on the list and doesn't seem
to match the actual data that Henry Thompson provided. Frankly, this
looks like compromise language based on someone getting cold feet
about treating forward proxies as YAGNI.

As language trying to communicate lack of confidence in treating
forward proxies as YAGNI being unambiguously the right call, I think
the language inappropriately states something too much in the other
direction without the statement having been shown to be backed by
evidence on the list. Considering the lack of evidence (e.g. cache hit
rates from some remote-island proxies and how overwhelmed the uplinks
would be without the proxies), saying "it is still useful" seems
pretty unscientific. Also, "in some cases (in particular, access from
limited networks), highly desirable" comes with a high risk of getting
read too broadly. (Forward proxies [that only cache and don't
recompress] don't even theoretically help when the network limitation
is between the browser and the proxy.)

In the light of http://ietfmemes.tumblr.com/image/102501920749 (Alt
text: Ancient aliens guy says: "I'm not saying I want to MITM https,
but I want to MITM https.") and there still being proposals to the
IETF that are stuck to the notion that confidentiality, integrity and
authenticity are OK for financial stuff but not so great for the rest
of the Web (https://tools.ietf.org/html/draft-reschke-objsec-00), I
think it's a bad idea for the TAG to suggest that "it might be so
desirable that networks require users to accept TLS Man-in-the-Middle"
especially when the circumstances where the statement might apply
could be read broadly.

If the TAG is shy to confidently put forward proxies in the YAGNI
category and needs some non-committal language, please don't claim
things like "is still useful" without evidence and please avoid giving
ammo to those who want to MITM. I suggest something like this for
hand-wavy non-committal language (in place of the quoted part starting
with "However" above):
"However, it is still possible that networks whose link to the
Internet backbone is very constrained could benefit from shared
caching. We encourage more research of such networks and, if the
research shows that there are still notable benefits to be had from
shared caching, exploration of mechanisms how such networks could be
better accommodated without compromising the confidentiality,
integrity and authenticity of Web traffic."

2:

Under "Browser Policy APIs", please replace "as new APIs in Web
browsers" with "as new APIs for Web browser extensions" to make it
clearer that Web content shouldn't be allowed to put your browser in
prison mode. (It might also be worthwhile to edit the text the look
less accepting of "think of the prisoners" line of anti-https rhetoric
when the rhetoric is addressed.)

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/
Received on Monday, 12 January 2015 15:37:14 UTC

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