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

[Yoav Nir <[e-mail]>]

On Aug 14, 2013, at 8:20 PM, Trevor Perrin <[e-mail]>
 wrote:

> 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.

Sure, we can.

>> 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?

Since pins have an OR relationship between them, a UA has to record all the possible pins, or none. If we get "pin-sha1=xxxxxxx ; pin-named=honest-abes-used-cars-and-certificates.com" and you note only the one you understand (the first), you will block access to the site if the certificate turns out to no longer fit the first pin, even if it does fit the second pin.

So at least new pin encodings need to be critical.

> 
>>>> 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 fine for a browser, but website administrators will also be required to check whether the string that they entered still means what they though it means. They will be required to check this periodically.

>> 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.

I think the browser-CA communications is the easy part. It's the CA-EE communications that is hard.
> 
> 
>>>> 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.

+1