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

[Chris Palmer <[e-mail]>]

On Wed, Oct 17, 2012 at 7:23 AM, Tom Ritter <[e-mail]> 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
[e-mail].) 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!