On 20/02/14 11:18, Yoav Nir wrote: > On Feb 20, 2014, at 12:29 AM, Chris Palmer <[email protected]> wrote: > >>> Section 2.5. >>> Section 2.4 says that future versions may add new algorithms. So we should >>> be prepared for new algorithms. Section 2.5 says "For forward compatibility, >>> the UA MUST ignore any unrecognized Public-Key-Pins header directives, while >>> still processing those directives it does recognize." So suppose the UA got >>> the following header: >>> >>> Public-Key-Pins: max-age=2592000; >>> pin-sha4-256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; >>> pin-sha4-256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ=" >>> >>> Not having support for SHA4, it can't validate or use these pins. That is >>> fine when the server keys are not yet pinned. Now suppose that the server is >>> pinned (because previously it expressed HPKP with a SHA2-256. Does the UA >>> (a) ignore it, keeping the old pin, or (b) treat this as unpinning? Either >>> way, where does it say so? >> I don't think the text currently handles this case. And, I don't know >> which of (a) or (b) is preferable. >> >> It's a bit of a pathological case; why would a site operator send such >> a header, knowing as they do that the current version of HPKP >> specifies only SHA-256 (i.e. SHA2-256)? >> >> In future versions, in which we hypothetically add support for SHA4 >> (or whatever future hash function), presumably we'd include some >> language about this. But for now, any site operator doing this would >> be making a mistake. > I think we do need to specify how an implementation of *this* spec deals with > unknown hashes. Imagine that this technology came about 15 years ago, and > that many websites had "pin-sha1" headers. Then in 2006 we realized that > SHA-1 was no longer considered secure, and wrote a new RFC with pin-SHA256 > (that was the new thing in 2005). Now it's 2014, and a site operator believes > that everyone's browser supports the new standard, so he replaces the > pin-sha1s with pin-sha256s. As it turns out, some browsers only started > supporting the new standard in 2009, and some people are using an unupdated > browser from 2008. > > Back to the real world, we don't have to say how to handle pin-sha4 > directives, but we do have to specify how to handle pin directives that we > don't recognize. Section 2.5 says: > For forward compatibility, the UA MUST ignore any unrecognized > Public-Key-Pins header directives, while still processing those > directives it does recognize. Section 2.1 specifies the directives > max-age, Pins, includeSubDomains, and report-uri but future > specifications and implementations might use additional directives. > > I guess "ignoring" is similar to omitting or filtering out, so my > hypothetical header from above reduces to: > > Public-Key-Pins: max-age=2592000 > > What do we do with this, (a) or (b), and where does it say so. BTW: I'm not > sure how servers can disable pinning. "max-age=0" is given as an example, but > reading section 2.5 strictly seems to suggest that even with max-age=0 you > need one valid pin from the certificate chain, and one valid pin not from the > certificate chain. This makes the above example non-valid, so it shouldn't be > noted, but it's weird that you require pins to unpin.
<no hat> in case of an unrecognised pin-shaX, scenario (a) would result in a potentially dangerous situation, that can brick the site, i.e. make it unavailable. If the new pin is ignored, i.e. not noted, that would mean the old pin would remain in place for the full period of time, even though maybe the new cert will be active soon and the old one no longer available. So I am afraid we probably need to entertain (b)? Best regards, Tobias > Thanks > > Yoav > > > _______________________________________________ > websec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/websec _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
