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

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://". 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?

I suggest tweaking the wording to acknowledge that some people may try
to do something but without suggesting that it's endorsed or
desirable. Considering that you didn't use my previous suggestion as a
whole, I now suggest replacing the sentence starting with "However"
with "However, shared caching is still considered desirable by some
and, in some cases, it might be claimed to be so desirable that it is
used as an excuse to make users accept TLS Man-in-the-Middle, which is
a bad outcome for Web security overall."

> From my standpoint, I think we need to walk the line between acknowledging that when someone (e.g., your employer) owns the machine, they can and sometimes do MITM, while not condoning that as a desirable outcome. That's why the draft encourages work on browser extension APIs, improving PKI UX, etc.

I'm not against acknowledging that certain bad things happen. I just
think the TAG should be careful that those who want to do those bad
things don't end can't twist the Finding to claim it endorses their
actions. (It's especially bad when "those" end up being regulators as
in the case mentioned by Mark Watson.) For example, I think the
wording in the quoted part immediately above would be careless in the
Finding (though it's just email text and not Finding text--but still
works as an example), because "can" is ambiguous in terms of "are
allowed to" (which isn't by any means something on which global
consensus applies either ethically or legally) vs. "are technically
able to" (which is obviously true).

> To the latter point -- I still find it remarkable that this is extremely common practice:
>    http://ist.mit.edu/certificates

For shame. That doesn't even seem to be motivated by a shared caching
pretext but by a desire to run an in-house CA. (Can doing that
*properly* really be cost-effective compared to purchasing
publicly-trusted certs?) MIT really should get publicly-trusted certs
for those services.

(To be fair, though, it's a failing on the part of the browsers that
the user can't constrain a CA like this to mit.edu.)

-- 
Henri Sivonen
hsivonen@hsivonen.fi
https://hsivonen.fi/

Received on Friday, 23 January 2015 14:39:56 UTC