W3C home > Mailing lists > Public > public-webappsec@w3.org > July 2015

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

From: Brian Smith <brian@briansmith.org>
Date: Mon, 6 Jul 2015 14:14:03 -0400
Message-ID: <CAFewVt60Wm+A4is6v53=v2PA9ODB0Jqf4KwB1S_7ohSzUC1Xdw@mail.gmail.com>
To: Ryan Sleevi <sleevi@google.com>
Cc: Mike West <mkwst@google.com>, Anne van Kesteren <annevk@annevk.nl>, "public-webappsec@w3.org" <public-webappsec@w3.org>, Dan Veditz <dveditz@mozilla.com>, Wendy Seltzer <wseltzer@w3.org>, Brad Hill <hillbrad@gmail.com>, Kristijan Burnik <burnik@google.com>
On Mon, Jul 6, 2015 at 1:17 PM, Ryan Sleevi <sleevi@google.com> wrote:

> On Mon, Jul 6, 2015 at 10:14 AM, Brian Smith <brian@briansmith.org> wrote:
>> 1. Nobody implemented it, so we don't really know if it can be
>> implemented. In fact, my understanding, from observing Google's work on
>> SHA-1 deprecation, is that it is actually much harder to implement than was
>> originally thought.
> hard from policy, not from code.

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.

> Part of the reason it's important is I think to highlight the fact that
> blocking *may* require first making the connection. That is, put
> differently, it would be a somewhat limiting design choice to always assume
> that blocking can be done before any data is sent on the wire.

Having MIX talk only about pre-connection/pre-fetching blocking wouldn't
restrict other specifications (or even later versions of MIX) from
specifying post-connection blocking. I hope that we can keep it so that
mixed content blocking is done before any *application* data is sent, at
least, although with 0-RTT stuff in TLS we might have to have a very
specific definition of "sent" that doesn't preclude it.

> To be clear, I support the abstract idea of blocking deprecated
>> TLS-protected subresources, and I do think that a specification for how
>> that should work should appear in a future version of some specification,
>> but not the current one.
> When you say "not the current one" - do you mean not MIX at all? Or not
> this version of MIX?

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.

Received on Monday, 6 July 2015 18:14:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:49 UTC