On Mon, Jun 22, 2015 at 10:00 PM, Brian Smith <brian@briansmith.org> wrote: > On Mon, Jun 22, 2015 at 7:17 AM, Mike West <mkwst@google.com> wrote: > >> 1. I've dropped the "at risk" note for "deprecated TLS-protection": >> https://github.com/w3c/webappsec/commit/5dd23ba69ecd39a45eceff86533dfb91f0ab645c >> (CCing Brian, who I believe was interested in the opposite, and Ryan, who >> might or might not have implemented the SHA-1 bits for Chrome). >> > > I don't have any problem with the idea of specifying/recommending > particular behavior for "deprecated TLS-protection." I think whether or not > it should remain in the spec, at this point, depends on whether at least > two independent implementations of it currently exist. > I missed this response, sorry! I think it's important that the spec leave us the flexibility of doing mixed content checks based upon data that we can only know after connecting to a server and poking at a handshake. It's certainly the case that we have concrete plans (and, I think, implementation (Ryan?)) to do this in Chrome. I'd prefer to leave the concept in the spec for that reason. Another option that I could live with would be to drop the concept from the spec explicitly, and to simply rely on Fetch's "HTTPS State <https://fetch.spec.whatwg.org/#concept-response-https-state>" in https://w3c.github.io/webappsec/specs/mixedcontent/#should-block-response. This has the practical effect of making it possible for Chrome to continue our SHA-1 deprecation plans, simply deferring the conversation around "deprecation" from MIX to Fetch. I'm not sure that's an improvement. WDYT, Brian and Anne? -mike
Received on Monday, 6 July 2015 14:52:21 UTC