On 07/31/2013 11:22 PM, Trevor Perrin wrote: > If other people want to write their own specs to add data into it, > that's great - it's a convenient single place for browsers and web > crawlers to find security policy for a site.
I'm finding myself more and more convinced by the well-known URI suggestion as well, despite the PITA that overhauling the spec is likely to be. Headers usually say something about a given HTTP request; the headers we're discussing here say something about the site as a whole. In addition to the extra overhead of re-evaluating the header on each request, there is a potential security hole for sites which permit users to control some subtree of the URL space. For example, if the administrators of https://example.net/ allow the user foo to publish arbitrary content below https://example.net/~foo/, and that user emits an HPKP header, they could potentially override the backup pins offered by the site administrator, or set an HSTS header with includeSubDomains that would cause other unrelated requests to fail closed, potentially for weeks or months depending on the max-age. Control of a specific well-known URI seems more likely to be restricted to the administrator. With a well-known URI, there are probably still caching issues to stake out; how often should a browser update its security policy for a given site in the absence of standard HTTP caching headers from the server? Or is it a MUST that the well-known URI needs to publish caching headers? --dkg
signature.asc
Description: OpenPGP digital signature
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
