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. > 2. The specification would be simpler without it. In particular, without > the deprecated TLS stuff, it could be made much clearer that the blocking > described in the document always happens before any data (HTTP request, > Websocket handshake, etc.) is sent on the wire. (Note that I think that CSP > should be defined to work like that too.) > 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. Now, we can say to introduce it later, but to the extent it affects design, it may help more to highlight up front. > 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?
Received on Monday, 6 July 2015 17:18:00 UTC