> > However, the same is true for HSTS, CSP, and any other policy-conveying > > header. > > It's not exactly the same - HSTS does not interpret an absent response > header as max-age=0, so the headers doesn't need to be sent on every > response. HSTS headers are also smaller.
This is a big issue I wouldn't overlook. In my experience looking at web crawls and trying to determine which sites are consistently setting HSTS, almost nobody consistently sets the header for every path and subdomain within a domain. For HSTS, this is okay as pointed out, but for HPKP I expect this will lead to a lot of accidentally clearing of pins. So we should think about what makes life easiest for server admins deploying HPKP in addition to efficiency. This could be argued either way-if servers aren't disciplined enough to always set the header, they may not be disciplined enough to always satisfy their own pins and they'll hang themselves that way. Serving everything satisfying a set of pins is strictly harder than serving everything over HSTS, and that's an issue. On the other hand servers will be more motivated to fix anything they serve not satisfying pins, since clients will lose access and complain, whereas accidentally clearing client pins by not setting the header is a siient failure. Personally I'd advocate strongly for a well-known URI. This is a tragedy of the commons-if every working group uses a header since this is a little less work, we end up with lots of headers being set and it being much harder for everybody to manage than a well-known URI specifying all TLS policy would be, as well as far less extensible. As an example, it would be useful during the rollout of Certificate Transparency if sites can specify that they are a "CT required" domain before this policy could be turned on by default for every domain in the world. Should this be another new header "Strict-Certificate-Transparency"? An extra directive for HSTS? Having a simple JSON file at a well-known URI to add a new field to makes much more sense.
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
