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

Re: Draft finding - "Transitioning the Web to HTTPS"

From: Mark Watson <watsonm@netflix.com>
Date: Fri, 23 Jan 2015 07:10:20 -0800
Message-ID: <CAEnTvdBqtVQD=Q=ksHF+pBZsch7NgHD3wOn51u=t5sFd4g3ZAw@mail.gmail.com>
To: Henri Sivonen <hsivonen@hsivonen.fi>
Cc: Mark Nottingham <mnot@mnot.net>, Chris Palmer <palmer@google.com>, Noah Mendelsohn <nrm@arcanedomain.com>, "Michael[tm] Smith" <mike@w3.org>, Tim Berners-Lee <timbl@w3.org>, Public TAG List <www-tag@w3.org>
On Fri, Jan 23, 2015 at 6:39 AM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:

> On Mon, Jan 19, 2015 at 7:53 AM, Mark Nottingham <mnot@mnot.net> wrote:
> >> On 16 Jan 2015, at 12:58 am, Henri Sivonen <hsivonen@hsivonen.fi>
> wrote:
> >> I think the TAG finding shouldn't suggest that MITMing https might be
> >> OK in some circumstances, because then those who want to MITM could be
> >> emboldened to MITM and to claim that whatever they do is endorsed by
> >> the W3C--all without giving users an opportunity to make an informed
> >> choice and without actually matching the circumstances that the TAG
> >> might have had in mind.
> >
> > The draft currently says:
> >
> >> 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://".

​Metadata also "disallows" caching in standards-compliant devices, since
following those is a MUST-strenth requirement in the HTTP RFC.

I think violating a MUST requirement qualifies as "it's disallowed, but I
did it anyway".

I suggest changing "discourage" to "disallow" and "disallow" to "prevent"
in the above sentence.


> However, shared caching is still considered desirable by some (e.g., in
> limited networks); in some cases, it might be so desirable that networks
> require users to accept TLS Man-in-the-Middle -- which is a bad outcome for
> Web security overall. Therefore, we encourage exploration of alternative
> mechanisms that preserve security more robustly, such as certain uses of
> Subresource Integrity [SRI].
> >
> > Is that adequate, and if not, can you suggest edits?
Received on Friday, 23 January 2015 15:10:48 UTC

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