Re: CfC: Mixed Content to PR; deadline July 6th.

On Mon, Jul 6, 2015 at 11:14 AM, Brian Smith <brian@briansmith.org> wrote:

>
> It depends on how things are specified, right? For example, the
> specification could be technically burdensome for Google, e.g. if it is
> required that the browser always attempt to try the cert chain that the
> server sent in the TLS handshake before concluding that the connection
> should be blocked due to SHA-1 deprecation. Without specifying such things,
> we can't really expect interoperability, but the better defined the
> mechanism is, the more likely there will be things that are technically
> and/or politically difficult for multiple implementations. Whether
> difficulty is political vs. technical also doesn't seem to matter much.
>

I think you've missed my point. This is very much a browser policy hook.
While flag days are good in theory, they suffer from the collective action
problem, and it's clear that different browsers have different priorities
and preferences with regards to how things change.

I don't think there is any traction for specifying what chain building
algorithm a browser should use - that's been beaten to death in IETF PKIX's
WG for over a decade, so I'm somewhat surprised to hear you suggest it
here, since the issues are well discussed (and, arguably, well documented -
RFC 4158 captures many of the different concerns)

I'm not trying to be dismisissive of your concern - but look at how we got
to MIX in the first place. It was only because browsers independently made
calculations about the compatibility risk / security risks and their target
user bases. As more progressive browsers worked through the first mover
problems (such as blocking mixed content XHRs and mixed content WSS), they
necessarily decreased the compatibility risks for more conservative
browsers, such that we're finally at a point in which the compatibility
risks are low and that normatively specifying these has a viable chance of
consensus. But it'd be mistaken to think "We're done here", and that's why
the policy escape hatch exists - a reflection of the fact that "While we
all agree on X, we also realize that Y may need tweaking over time".

Given that the preference is for the spec to reflect the implementation
reality versus the aspirational reality, I don't see how we can reasonably
put something forward that reflects the present reality without
acknowledging, implicitly, that there is more aspirationally.


> I think it's best to advance a MIX 1.0 that specifies what has been
> interoperably implemented, which is (only) the pre-connection blocking
> behavior. When the post-connection blocking behavior is more thoroughly
> specified, it might overwhelm the rest of MIX, so it might be better put in
> a separate document.
>

To the extent the current spec should reflect the reality, I agree.
However, I think it'd be mistaken to conflate interoperably implemented
with a desire to limit escape hatches.

Put differently, I'd much rather a 'map of the world' that covers the known
world, and then indicates 'here be dragons' in the unknown portions than a
map of the known world that claims to be a map of the /whole/ world.
Hopefully the semantic subtlety is clear.