Hi I agree with Tobias.
The attack that Trevor describes is done by a TLS MitM. TLS MitM can be either trusted or not trusted. Non-trusted MitM is not a problem. Even if the user is allowed to click through the interstitial and get the page, the browser still considers the connection insecure (red slash in the UI of Chrome) and the draft says not to note a pin in that case (Section 2.5: "It received the PKP response header field over an error-free TLS connection.”) Trusted MitM are a bigger issue. I know that Google’s implementation disables pinning for trusted MitM, but even UAs that won’t make a distinction between regular trusted CA and MitM CA won’t pin the data, because the pins (that come from the origin server) will not match the public keys (that come from the proxy). The only issue is if the MitM is malicious and stores its own pins via the PKP-RO headers, causing the UA to be tracked by sending reports to the attacker whenever they access the website. I think it’s important in this case that the MitM is trusted, meaning that the user (or their IT department) installed that root trust anchor. In that case the user has to trust that this root CA won’t do harm. That’s part of the trust. This scenario may deserve a sentence or two in the security considerations, not a change in the protocol. Yoav (with chair and shepherd hat on) _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
