On Feb 27, 2014, at 1:05 AM, Trevor Perrin <[email protected]> wrote: > > On Wed, Feb 26, 2014 at 1:44 PM, Ryan Sleevi <[email protected]> > wrote: > > In attempt to resolve your outstanding issue(s) with PKP-RO, I want to > first ensure that this proposal makes sense. If we're in agreement, we can > work on adding it to the next draft. > > PKP > - Persistently recorded > - Expires based on max-age > - Causes all subsequent connections since 'noting' fails > - Note that this is somewhat ambiguous within a UA that has multiple > simultaneous connections, and for which header parsing may happen at > any arbitrary time. > - _HOWEVER_, I think this is best left up to implementations, since > the external effects are consistent with how the server/service sets > up resource fetching. > > PKP-RO > - Not persistent > - Applies only to the _single_ transport connection > - Because HTTP connections MAY be kept-alive or re-used, to further qualify > - Is evaluated upon receipt of the header, for the response it's > included in. > > > That's the simpler of the options. > > It means PKP-RO only tests whether the browser builds a chain you expect at > one moment in time. It doesn't test whether the site is serving the correct > certs for different URLs (e.g. includeSubdomains), so it's not a thorough > test (i.e. the lack of reports doesn't provide much confidence that the PKP > header is safe). > > It also doesn't have any security value. > > I don't hugely object to this, but given its limitations I'm not sure it's > worth the effort. > > Curious what other people think.
Not much for security, because anyone who can mess with the certificates that you’re seeing can also mess with HTTP headers. But it does provide a good mechanism for the administrator to avoid shooting himself in the foot. For example, if the administrator wants to use the pin-sha4 directive from the other thread and one of the browsers and some browsers doesn’t support this directive, then having the SHA-4 pins in PKP-RO for a few days will generate some reports, and the administrator might decide that it’s not yet time to move to SHA-4. Another example, if the administrator calculated the has wrong (like hashing all the certificate rather than SPKI) they will also get reports. Unfortunately is doesn’t help with the issue of replacing the certificate with one whose chain is not covered by the pins - that’s the one that bricks your site. PKP-RO does not help this, but it still has some value. Yoav
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
