Re: [websec] New draft of HTTP header-based public key pinning

[Chris Palmer <[e-mail]>]

On Tue, Nov 8, 2011 at 4:31 PM, Tom Ritter <[e-mail]> wrote:

> I believe 'directives' should replace "fingerprints" with "pins":
>
>   directives      = max-age LWS ";" LWS pins
>                     / pins LWS ";" LWS max-age

You are right. Fixed.

> I think this paragraph is misworded:
>
> UAs MUST have a way for users to clear current pins that were set by
>   HSTS.  UAs SHOULD have a way for users to query the current state of
>   Pinned Hosts.
>
> Instead of HSTS, should that be "Public Key Pinning"?  If not, pins
> set during HSTS must be flagged and treated differently - why?

You are right. I now say:

UAs MUST have a way for users to clear current pins for Pinned Hosts.
UAs SHOULD have a way for users to query the current state of Pinned
Hosts.

>  - There is no directive or suggestion to User Agents about saving or
> not saving pins received in a private browsing mode.  Maybe there
> shouldn't be, but if a User-Agent does save them, the same 304/ETag
> trick malicious sites use to track users can be created using certs
> and subdomains.

Yes, another person raised this concern, and it is real. I don't see a
way to resolve this problem; perhaps I am not smart enough, but I
can't see a way to have both dynamic pinning AND avoid this tracking
attack.

I am willing to add a paragraph about what browsers should do in
private browsing mode, and I am willing to go either way on what the
requirement should be. I don't know what is best.

>  - The "Pinning Self-Signed End Entities" section was a bit confusing,
> I had to read it a couple times to be sure you were talking about a
> server's self-signed cert, and not a client cert.

Now I say:

If UAs accept hosts that authenticate themselves with self-signed end
entity certificates, they MAY also allow hosts to pin the public keys
in such certificates. The usability and security implications of this
practice are outside the scope of this specification.

Is that better?

>  - The Pin-Break mechanism gets more complicated which each revision.

Yeah, that's why I just dropped it.

> I know it's being shopped around for both this and the approach to put
> pinning in the TLS layer (TACK), but does its removal implies pin
> break codes are not intended to go into the final version of this
> document, or will it be added later after the first bit is worked out?

For now my plan is to ship a trial implementation of HTTP header-based
dynamic pinning without pin break codes, and see how people like it.
It might turn out that nobody likes pinning at all, or that people
like X.509-based dynamic pinning better, and either approach with or
without TACK/pin break codes. To get that trial implementation off the
ground, I'm doing The Simplest Thing That Could Possibly Work.

If it happens that (a) we standardize it without pin break codes and
(b) after a year everyone says, "this is great but it really needs pin
break codes to be awesome", we'll just update the spec and the
implementations.