Re: [websec] #60: Well Known URIs vs Response Headers

[Trevor Perrin <[e-mail]>]

On Thu, Aug 1, 2013 at 9:24 AM, Chris Palmer <[e-mail]> wrote:
> * Regarding generic security policy URI: If we can't achieve consensus
> in this WG, why would adding dependencies on more WGs and W3C help?
> Obviously, it would not. Thus, we should stick to defining only
> pinning policy in this draft.

Definitely.


> It does make more sense to try to make it
> generic to transport security, but even then, it's optional and Jeff
> Hodges might be tired and might not want to specify JSON syntax for
> HSTS... Jeff?

If we go the .well-known URI route, it might as well be extensible to
"similar things", though I agree we shouldn't spend effort on them
now.


> And it doesn't make much sense to put TACK policy in the
> resource, does it? TACK is all at the TLS layer.

It might make sense, at some point.  TACK is mainly just a key that
can be pinned.

TACK has its own way of asserting pins (setting an "activation flag").
 But if you leave the flag cleared then a tack is just a signing key
and signature.  Other layers could assert pins to the signing key,
perhaps to add features like HPKP's "report-URI" or "strict" or
something.

Not saying that's a great idea, but it's not crazy...


> * "possibly dozens of hashes": As we can see from Chrome's
> net/http/transport_security_state_static.json, Twitter does indeed
> trust a huge number of signers in its static key pins. I hope that
> Twitter is an outlier in this, and that sites don't start needing to
> trust so many signers. (Google uses fewer pins, for example.)

They may be an outlier, but we don't really know.  Sites might want
very safe pins that list several CAs, so they have backup options.
And apparently some CAs have several keys (11 for Verisign?  7 for
GeoTrust?)


> But,
> maybe not, and maybe header bloat will become a concern. (Even so,
> wake me up when response body bloat is no longer a concern...) But we
> can resolve that problem with trust anchor names in place of SPKIs
> just as easily as with a W-K URI.

Agreed.

If we had to solve this one way or the other, I'd prefer to do pinning
CA names, because I think it solves a bigger useability problem for
sites.


> * We could also relax the requirement to send the PKP header on each
> response. To be honest I can't recall now why we required it, but it
> seems like it resolved some security concern? Maybe it's in the
> archives...

I don't recall it being discussed.  I do think this requirement could
be relaxed.


Trevor