On Fri, Nov 29, 2013 at 11:47 PM, Ryan Sleevi <[email protected]> wrote: > On Fri, November 29, 2013 8:44 pm, Trevor Perrin wrote: >> On Fri, Nov 29, 2013 at 4:14 PM, Ryan Sleevi <[email protected]> >> wrote: >> > On Fri, November 29, 2013 12:24 pm, Trevor Perrin wrote: >> >> >> * Why is there a "Public-Key-Pins-Report-Only" header instead of a >> >> "report-only" directive? Most of the document is written as if there >> >> was a single "PKP header field", so a directive would make more sense. >> > >> > Similar to CSP. A PKP might specify a looser-policy, while >> > PKP-Report-Only >> > is used to test a more restrictive policy for deployment. >> >> So the UA is going to maintain 2 stores of pins ("PKP" and "PKP-R-O"), >> and process the "PKP" and "PKP-R-O" headers only against the >> appropriate store? >> >> That means asserting PKP:<new-pin> isn't sufficient to overwrite >> existing pins. You'd also have to assert PKP-R-O:max-age=0. >> >> Seems OK, but none of this is in the draft. > > An artifact of when a PKP header was required (eg: implicit Max-Age). This > is because Report-Only doesn't/wouldn't need to be stored, because it is a > report-only mechanism. You simply evaluate the R-O on the current > connection (if a directive is present) and ping back.
Hmm, I assumed "report-only" pins would be noted, and the draft seems written that way. To step back: It's hard to read this draft and understand how "strict", "report-only", or "preloaded" pins should be handled. It seems these concepts were bolted-on to the draft without being fully integrated. Also, processing rules are scattered throughout, so it's hard to get a clear view of what happens during (A) processing an HPKP header, and (B) validating a connection. The draft could use an editing pass that doesn't change the protocol (from the authors' understanding), but clarifies these things. >> >> * In draft-05, client processing was changed from noting a single >> >> "expiry" value to noting two values: "Effective Pin Date" and >> >> "max-age". The previous approach was simpler, stored less data, and >> >> was more aligned with HSTS. > > Yet was very much intended to address the same concerns you raised > regarding the intersection between 'preloaded' and 'dyamic' pins, and the > WG seemed to support. > > Do you have a proposal on how to reconcile these two items? I propose that pin expiry should be handled in the older, simpler way, consistent with HSTS (noting a single "expiry" value). I understand that tracking the "Effective Pin Date" was added to support the "most recently observed" policy in 2.7. As I've argued in [1], I think that policy is overly complex. There are simpler policies which UAs should have the freedom to choose. Anyways, maybe you could respond to [1], and we could separate out that discussion. >> >> * Section 2.6 mandates "When a UA connects to a Pinned Host, if the >> >> TLS connection has errors, the UA MUST terminate the connection >> >> without allowing the user to proceed". HSTS allows the server to >> >> specify this, so it seems unnecessary and inflexible to mandate it >> >> here. It's also unclear whether a "report-only" pin counts as a >> >> "Pinned Host". >> > >> > This is a feature, not a bug. >> > >> > PKP is useful without mandating HSTS. However, the security advantages >> > of >> > PKP can be undermined, much the way HSTS's can, if the UA allows users >> > to >> > bypass. >> >> I think it's a mistake to mandate UI here. "Users clicking through >> legitimate security errors" is one risk. "Users being denied access >> to legitimate sites due to pinning failures" is another. >> >> It's hard to know how to balance these. We should allow UAs latitude. >> I suggest changing the text from MUST to SHOULD, at minimum. > > Thanks for your feedback. I'd like to hear from others in the WG if that > view is shared. To this point, we haven't heard any concerns about the > MUST, and the security properties are seemingly well understood. > > Certainly, no UA vendor has asked or proposed such latitude. But then > again, we're all individuals here. I do fail to understand your > distinction between "legitimate security errors" and "pinning failures". Pinning is risky. Sites could make a mistake that renders them unreachable. This could be mitigated by "softening" UA behavior when pin validation fails, e.g. silent-fail (with reporting), or soft-fail (that can be clicked through) instead of hard-fail. There are complex usability / security tradeoffs here. I submit we don't have enough experience with pinning to mandate a specific UI. >> >> * Why is SHA1 supported? If the reason is size, why not remove it >> >> but allow the server to pin to a truncated hash (e.g. pin to the first >> >> 16 or 20 bytes of SHA256) >> > >> > I won't attempt to assume any argument for you, but it sounds like you >> > oppose SHA-1. Perhaps you could state that, and your reasons why. >> >> It's weaker than SHA-256. I don't see a reason to bother with it. >> >> It seems better to steer everyone towards one hash algorithm, to make >> comparing pins easier. >> > > Size, speed, and simplicity were primary motivations, and the security > risks at this time are mild to non-existant - particularly given the lack > of latitude to mount attacks using the structured nature of the SPKI. > > However, if you follow discussions in the CA/Browser Forum with respect to > Microsoft's plans to deprecate SHA-1, you will see that a number of CAs > have reported vendors/products that don't support SHA-256. SHA-256 is mandatory for HPKP, so they'll have to add it. Anyways, I suggest replacing SHA-1 with SHA-256 truncated to 128 bits. For example: Public-Key-Pins: sha256-128=<sha256-128>, sha256=<sha256> This is simpler for the UA, as it only needs to calculate one hash on each SPKI in the chain (instead of two). It's also more usable for deployers, since the same SPKI can be recognized whether it's hashed in short or long form. It's also more compact, and a stronger cryptographic hash (given current state of cryptanalysis, e.g. [2]). >> >> * Should the header name be changed once this draft stabilizes, to >> >> ensure no bad interactions with UAs that implemented earlier drafts? >> > >> > This seems premature at best, but more likely an unwarranted and >> > unnecessary change. >> >> Chromium has had evolving, partial support for HPKP for some time. >> Have these partial versions been shipping? >> >> Are they likely to be "in the wild", with odd behavior that >> HPKP-asserting sites might trigger? > > Chromium does not ship versions. > Chrome, which is based on Chromium, releases new versions approximately > every six weeks. It has been successful in following the ongoing > standardization processes of a variety of specifications - in the IETF, in > the W3C, and in the WHATWG - and updating implementations accordingly and > (nearly) completely Beyond just spec changes, I'd be concerned about code quality. Chromium has had evolving code to do *something-or-other* in response to the "Public-Key-Pins" header for over a year. This code is a work-in-progress (in my opinion). Some versions of it seem like they might have problems such as applying a pin for a longer expiry than was asserted, or with incorrect include_subdomains. If I was a site contemplating turning on the HPKP header, this would make me nervous. Renaming the header seems a trivial fix to avoid any risk here. Trevor [1] http://www.ietf.org/mail-archive/web/websec/current/msg01938.html [2] https://marc-stevens.nl/research/papers/EC13-S.pdf _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
