Re: [websec] #58: Should we pin only SPKI, or also names

[Trevor Perrin <[e-mail]>]

On Tue, Aug 13, 2013 at 2:42 AM, Gervase Markham <[e-mail]> wrote:
> On 13/08/13 07:40, Trevor Perrin wrote:
>> Names are also smaller, and easier to configure, review, and debug
>> than lists of hash values.
>
> Sure. No-one is denying that there are some advantages to using names;
> the question is whether those advantages are worth it given the
> significant downsides.

The only real downside I've heard is that this would be a lot of work
which people don't want to tackle now.

Which is fine, but I hope we can revisit this later.


> In terms of how to proceed, I suggest the wise thing is to define the
> syntax so it is open to being extended with names or other identifiers
> later, but get the standard done without that facility. Then, we don't
> have to let the best be the enemy of the good.

Per current spec, any new directives will be ignored by old browsers.

Do we want the ability for new directives to be somehow marked
"critical", so that an HPKP header is ignored if these new directive
aren't understood?


>>> It's well known and understood that not every user updates their browser
>>> every cycle. Or, when and if pinning is integrated into an OS, they don't
>>> always update their OS. So you will quickly have a situation, very easily
>>> within a few releases, of the name 'Foo CA' ambiguously referring to
>>> multiple different sets of SPKIs.
>>
>> Browsers would need to stop using name->key mappings that aren't
>> current (say, more than 30 days old).
>
> And so HPKP no longer works for those sites in those browsers? That
> doesn't sound great from a security standpoint to me. It also makes
> using names clearly worse for the site than using hashes.

HPKP pins based on stale name<->key mappings would not be applied.  I
think any instantiation of this concept would have to work that way.

A browser that's been somehow cut-off from security updates for a long
time will have other vulnerabilities (preloaded pins will be disabled,
security holes will be unpatched, blacklists and revocation data will
be absent, etc).


> That's rather a big change in the idea to be throwing in as a bullet
> point mid-way through a discussion. Forgive me, but it rather seems like
> you are making this up as you go along rather than having thought it
> through and presented a coherent proposal.

Well, I am.

The hard part of this is what communication / coordination / registry
mechanisms can be set up for CAs to coordinate this with browsers.  I
don't have a good sense of that.


>>> This is independent of mergers - CAs that are issuing new intermediates,
>>> or deprecating old roots, etc.
>>
>> Yes, but either these get tracked by browsers, or they need to be
>> tracked by every website using an affected CA pin.
>
> If the idea of using names is greater simplicity for sites, imposing a
> requirement that they track the goings-on in the CA industry seems not
> to meet that goal.

There's some misunderstanding.

My point is that changes like CAs issuing new intermediates or
deprecating old roots MUST get incorporated into website pins somehow.

Either every website using CA pins has to keep track of these changes
and make these updates (current system).

Or only the browsers have to do this (named pins).

Most of the objections people have been raising come down to: "Pinning
CA keys is hard, CA keys change over time and between root stores, how
could browsers possibly keep track of this..."

Any my counter is:  Yes!  It's hard!  Which is why I'd much rather
have a few browsers keep track of it then ask every website deployer
to do so.


>> I could imagine the former becoming widely used.  Websites could
>> easily see what other websites are doing, discuss and compare which
>> CAs they consider good choices, and test and review their deployments.
>>  CAs would be incentivized to opt-in to this system by making it easy
>> for browsers to pin them, and to provide good security so that
>> websites would choose to include them into pins.
>
> Can't CA's help in the current system?

Of course, and they'll have to.

The question is whether they should be publishing this data for every
pinned website to track, or every browser to track.


> "Here's the set of 3 opaque
> strings you should add to your HPKP header to pin to our consumer roots"
> is not all that much more complex than "Here's a string that looks like
> a domain name you should add to your HPKP header to pin to our consumer
> roots".

I disagree, configuring long lists of random-appearing strings that
require frequent updating is much harder than configuring a few
readable names that almost never change.

But I suppose this is a debate that can be resumed in a year or two
when we've got more experience.


Trevor