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. Cheers, Brian
Received on Monday, 6 July 2015 18:14:31 UTC