On Thu, May 1, 2014 at 1:34 AM, Yoav Nir <[email protected]> wrote: > > On May 1, 2014, at 12:41 AM, Trevor Perrin <[email protected]> wrote: > >> On Mon, Apr 28, 2014 at 11:24 PM, Yoav Nir <[email protected]> wrote: >>> >>> Having reviewed this, I think this version addresses all the issues raised >>> during WGLC. >> >> The added sentence in 2.7 on preloaded/dynamic pins doesn't match the >> rest of the text, which is written to mandate specific behavior. If >> we're not going to discuss implementation alternatives, we should just >> delete most of 2.7 and let implementations do what they want. > > Why? All the new sentence says is “The Effective Pin Date of built-in pin > lists is UA implementation-defined”. Implementations are still required to > treat the pre-loaded pins as though they have some effective date and > determine precedence by whichever has a later date.
That's a bad requirement, as it forces implementations to track the Effective Pin Date for dynamic pins (the Effective Expiration Date is not sufficient). Also, we talked about and I thought agreed to allow implementations freedom to decide how to handle preloaded/dynamic pin co-existence, as long as they don't apply a pin that was never asserted. For example, I described a reasonable implementation which this text would disallow: http://www.ietf.org/mail-archive/web/websec/current/msg02016.html I thought we had agreement to allow things like that: Yoav: "Yet a fourth way is to observer that none of this affects interoperability in any way and leave it up to the UA vendor to choose their way. The web site operator should only include valid pins in their HPKP headers, and they should also enter only valid pins in pre-loaded lists. They should also deal with the fact that don't control usage patterns, so anytime they pin something for X seconds, their website MUST conform to that pin for at least those X seconds or bad things will happen." http://www.ietf.org/mail-archive/web/websec/current/msg02019.html Trevor: "Your "fourth way" is well-put, and I agree - all of these seem valid implementations which should be allowed." http://www.ietf.org/mail-archive/web/websec/current/msg02020.html Chris Palmer: "I have been thinking that this 4th way is the way to go." http://www.ietf.org/mail-archive/web/websec/current/msg02022.html Dan Veditz: "The pre-load list seems outside the mechanism covered by the spec. At best the spec could mention it in a non-normative section as something UAs can do to cover the first-visit gap, but there are several valid ways such a list could be implemented." http://www.ietf.org/mail-archive/web/websec/current/msg02028.html You suggested a text modification which you maybe thought implemented that, and which Tom, Tobias, and Chris seconded: "Does anyone (and that includes the authors) object to relaxing the requirements in section 2.7, so that the choice of when the static pins are believed to have been observed is left to the implementer? If not, we'll resolve it that way." http://www.ietf.org/mail-archive/web/websec/current/msg02021.html But that doesn't satisfy what I think people wanted, so I think we should strip down 2.7 to something like your text above on the "fourth way". >> * Interaction with cookies needs discussion, at least in security >> considerations. Cookie scoping rules pose a serious problem for >> pinning, e.g. a pin at "example.com" could be undermined by a MITM >> inventing a "badguy.example.com" and using it to steal or force >> cookies. > > While there are similar concerns, I don’t see the interaction. If you are > example.com, and badguy controls badguy.example.com, then they’re going to > get your example.com cookies unless you can block it with scoping. HPKP > doesn’t help you there. You *can* block them with HPKP if their control on > badguy.example.com relies on a mis-issued certificate and you restrict them > with the includeSubdomains directive. The interaction is that the security you were hoping HPKP would give you for example.com will be largely ineffective if a badguy can forge a cert for badguy.example.com and you don't defend this with either (a) includeSubdomains or (b) cookie-scoping to the domain (which doesn't work on IE). So this is a security consideration deployers of pinning need to be aware of. Anyways, below is the text from TACK's security consideration which isn't perfect, but something like this should be added: HTTP cookies [RFC6265] set by a pinned host can be stolen by a network attacker who can forge web and DNS responses so as to cause a client to send the cookies to a phony subdomain of the pinned host. To prevent this, TACK HTTPS servers SHOULD set the "secure" attribute and omit the "domain" attribute on all security-sensitive cookies, such as session cookies. These settings tell the browser that the cookie should only be presented back to the originating host (not its subdomains), and should only be sent over HTTPS (not HTTP) [RFC6265]. Trevor _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
