On Thu, Aug 1, 2013 at 8:51 PM, Trevor Perrin <[email protected]> wrote:
> On Thu, Aug 1, 2013 at 9:24 AM, Chris Palmer <[email protected]> wrote: > > * Regarding generic security policy URI: If we can't achieve consensus > > in this WG, why would adding dependencies on more WGs and W3C help? > > Obviously, it would not. Thus, we should stick to defining only > > pinning policy in this draft. > > Definitely. I agree it wouldn't make sense to bog-down the HPKP spec with HSTS (and definitely not CSP). I think the question is, for the next HTTPS policy that sites may want to declare, can we make it as easy to do so as possible? CT is the right test case here because IMO it will be very useful to set a CT-required bit. If refactoring the HPKP spec to a well-known URI enables CT to push this through in a few months instead of a year, that's a nice benefit though still not the main motivation for switching to a well-known URI. > They may be an outlier, but we don't really know. Sites might want > very safe pins that list several CAs, so they have backup options. > And apparently some CAs have several keys (11 for Verisign? 7 for > GeoTrust?) > Another way of looking at this is, how can the spec be written to minimally disincentivize sites from adopting it? If sites want to pin but feel they can't deploy a pinning policy with less than Twitter's 19 hashes, and they have to add that to every response, some percentage may skip it that would have pinned if they weren't adding almost 1 kB to every response. That's the case I'm worried about. > If we had to solve this one way or the other, I'd prefer to do pinning > CA names, because I think it solves a bigger useability problem for > sites. Maybe I've missed this, but where is the mapping of CA names to keys defined? > > * We could also relax the requirement to send the PKP header on each > > response. To be honest I can't recall now why we required it, but it > > seems like it resolved some security concern? Maybe it's in the > > archives... > I'd strongly advocate for dropping this requirement, though I don't remember the argument for it either. As I've said, in my experience scanning HSTS headers it's rare to see them deployed 100% of the time. Here's an alternative approach I was thinking about which could fix any header-bloat concerns without naming CAs or switching to a well-known URI: add either a "policy-serial-number" directive to the HPKP response header, or have clients compute a hash of each policy they store (definitely doesn't need collision resistance and might not even need to be a crypto hash, not sure if there are attacks if it's just a CRC). If user agents have a cached policy for a site, they send a request header "known-hpkp-policy: " request header with the serial number or policy of the currently known policy. If the server sees this, it can respond with an abbreviated header of just "Public-Key-Pins: extend" which tells the user agent to re-up the current policy. That's it. They can always send a clear message or a new policy if they want. But in the case where header bloat may be a concern because you're doing hundreds of requests to a domain quickly, you can do it all in just a few bits... This adds moderate complexity to the spec and implementation, but probably much less than switching to a well-known URI.
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
