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

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.

…Mark




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