On Wed, Oct 17, 2012 at 7:23 AM, Tom Ritter <[email protected]> wrote: > Section 2.3 "Noting Pins": > > I wonder if it is worth moving "The UAs MUST ignore Public-Key-Pins > response header fields received on HTTP (non-HTTPS) connections." > outside the criteria to be unambiguous that a client should not > "discard any previously set Pinning Metadata" if it receives the > header over HTTP. Or if it's reasonable enough to assume no one would > get confused.
I think it's reasonable enough. However I did add this: """The UA MUST note the pins if and only if it received the Public-Key-Pins response header field over an error-free TLS connection. The UAs MUST ignore Public-Key-Pins response header fields received on HTTP (non-HTTPS) connections and on HTTPS connections that are not error-free.""" to (hopefully) resolve this: > Similarly, I wonder if there was some situation that could result in > an attacker-induced 'errored' TLS connection that still sent the > header, resulting in the data being discarded... Thoughts? > Section 2.4: "Validating Pinned Connections": > > For the purposes of Pin Validation, the UA MUST ignore > certificates who SPKI cannot be taken in isolation and superfluous > certificates in the chain that do not form part of the validating > chain. > > I know I just modified this, but the second phrase just hit me. > Because path construction is non-standard, could a client wind up in a > situation where the site pinned to CA_Alice, with the intended path > CA_Alice -> CA_Bob -> Intermediate -> Leaf; but because CA_Bob was > trusted, the ultimate validating chain was simply CA_Bob -> > Intermediate -> Leaf? I'm not sure what the right way to counteract > that would be... Yes, Ryan raised this hilarious point to me a while back, and now I see he has responded to your question here on the list. So, it's a strong motivating factor for a report-only mode. I've created an issue tracker entry and a discussion thread for that. > 2.5: "Pin Validity Times" > > I find the "current + current - initial" / "(b) the amount of time the > pin has been noted" item confusing, and am not sure what it means from > reading only the draft. If I'm not the only one, it might be worth > clarifying. Yes, even after a lot of thought I am still undecided about this. I see several possible approaches: (a) simply have the validity time be the same as for HSTS; (b) the same as HSTS but with a 30-day maximum; (c) the current attempt to mirror TACK, except clarified and with examples; or (d) something else. Of these, I think I currently like (b) best. Thoughts? > 2.6. "Interactions With Preloaded Pin Lists" > > If closing private browsing mode or clearing saved data also clears > preloaded pins (and I think it should), I think you mean "clears dynamic pins"? In Chromium's Incognito, any accrued dynamic pins will be lost when you close your last Incognito window. (If not, that is a bug and you can assign it to [email protected].) Also, in Chromium, when you clear browsing history, chrome://chrome/settings/clearBrowserData, *and you select "from the beginning of time"* (or presumably any time that predates when your HSTS data is from), your HSTS metadata (e.g. ~/.config/chromium/Default/TransportSecurity) is indeed wiped clean. That was true last time I checked, on 7 May 2012. Again, if you find otherwise, assign me a bug. > this would cause a revert to > the preloaded pins, which may break sites. A workaround may be to > disable a preloaded pin if a new pin is seen, and keep that disabled > even after the saved data wipe/private browsing mode close. Good point. I'll add a note to that effect and ship it in the next draft. > To prevent using this as a backdoor into tracking, I don't consider the implicit tracking cookie problem to be solvable. I think EFF's Panopticlick conclusively shows that it cannot be solved. Tracking with HSTS and HPKP metadata would be a notably noisy and inefficient way to implicitly track people; much "better" methods exist now and always will. See http://www.w3.org/TR/hr-time/ just as a random example... > the preloaded pins > should be sanity checked for "Is this organization likely to abuse the > feature." I suppose we could press the Safe Browsing list into service for this (and data and API for that are open), but it's a stretch. SB is about malware and phishing, which is a different thing than implicit tracking. It could at best be a "UAs MAY choose to ignore HSTS and pinning metadata for certain sites... a mechanism to do so is beyond the scope of this I-D..." thing. > Again, excited about this - thanks for the work. Thank you for all your help! _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
