Re: [websec] Fwd: New Version Notification for draft-ietf-websec-key-pinning-03.txt

[Tom Ritter <[e-mail]>]

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