Some musings after reading again: 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. 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... 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... 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. 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), 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. To prevent using this as a backdoor into tracking, the preloaded pins should be sanity checked for "Is this organization likely to abuse the feature." Again, excited about this - thanks for the work. -tom _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
