Ryan Sleevi <[email protected]> wrote: > Trevor Perrin wrote: >> Ryan Sleevi <[email protected]> wrote: >> > Trevor Perrin wrote: >> >> * 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 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". I > would certainly count the latter amongst the former, and so I fail to see > how the risks differ, beyond being a superset/subset.
I think it would be difficult for any UA to commit to implement this as written. For example, False Start intolerance is an error, but fallback when False Start intolerance is detected doesn't seem like something that should be prevented by pinning. (Especially if such intolerance can only be detected sporadically.) I suggest that the specific types of errors that UAs MUST terminate the connection for be enumerated (expired certificate, revoked certificate, receipt of any fatal alert in the TLS 1.0, TLS 1.1, and/or TLS 1.2 specifications, etc.). Then, leave the rest as SHOULD. Or, just make it SHOULD. >> >> * 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) > In short, I don't feel like it's a compelling reason not to include SHA-1 > at this time (but am happy to see if the WG, ADs, or CFRG feel otherwise), > but I would definitely have concern over the complexity of some truncation > schemes. Example concerns with the proposal include: Is it arbitrary or is > it fixed? If it's fixed, is the criteria size of the hash? Speed of the > hash? Some other criteria? I agree that SHA1 doesn't need to be supported and shouldn't be a MUST-support feature. Let's be nice to our future selves and save them the pain of having to decide what to do about SHA1 in 2017 or whenever. In general, I think that new standards at IETF should avoid making SHA-1 mandatory when there are no legacy compatibility concerns to deal with. I also agree that the complexity of specifying a truncation scheme is concerning, and I would avoid doing anything with truncation. If the examples in the draft are anything to go by, the difference in length of a SHA256 hash vs a SHA1 hash is not a huge concern, relative to the verbosity. > Firefox, which has supported HSTS and is working on (shipping?) HPKP > support, is likewise on a similar update trajectory and a similar > situation where users and sites face much more pressing concerns than > HPKP. Firefox isn't shipping any HPKP implementation, though we are interested in shipping some implementation key pinning, and we've done some incomplete work on an implementation of HPKP. Because we are (I am very) concerned about what a footgun HPKP could be, our rollout of an implementation is likely to be very conservative. For example, I doubt that we would support the "strict" directive initially, and I would not be surprised if we never supporting it. (I definitely support the removal of "strict" from this version of the spec.) > I would think that it would be much better addressed that, as we progress > through WGLC, IF we find we need to make backwards incompatible changes, > we can assess the risks then, rather than act on hypothetical concerns in > the present. This is a draft that has three authors, all from Google, and the only major UA implementation (AFAICT) is also Google-authored. Without a second, independent implementation, it will be very difficult to determine which changes need to be made to the draft spec. I think a good litmus test for determining when HPKP may be suitable to advance would be having https://www.google.com and other major websites send a non-report-only HPKP header to UAs that are not based on Chromium. See [1] for some evidence of why I think that is likely to be quite a ways off. [1] https://groups.google.com/d/msg/mozilla.dev.security/Cfi30mFNxd4/TMmkI2nmWlwJ Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
