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

From: Chris Palmer <[email-masked]>
Date: Thu, 1 Aug 2013 09:30:13 -0700

On Mon, Jul 29, 2013 at 9:13 AM, Phillip Hallam-Baker <[email-masked]> wrote:

> If we have a diginotar type situation again (FSM forefend), we want the pins
> to a root to be broken at the same time the root is unloaded, yes?

If the root of a site's cert chain --- really, any signer --- is
blacklisted or even just removed from the trust anchor store, pins and
Pin Validation are irrelevant since the chain won't validate. Pin
Validation happens only *after* all other certificate chain checks are
performed.

> The trust anchor data structures are outside the PKIX model but they browser
> providers do need to track them regardless. I would rather tie pins to the
> actual entity we want to pin to (the CA) rather than attempt pinning to some
> sort of proxy.

Allowing sites to pin to any point in the certificate chain is a
feature, not a bug. However, it will almost always make the most sense
to pin to one or more CAs. Thus, making that easy is a good goal.

> There are CAs that are not represented in CABForum but CABForum is a place
> where we can get a requirement of the form 'every CA must pick a DNS name as
> a unique identifier for their service and report it to the browser
> providers'. And that requirement will quickly become universal.
>
> While we could choose a different string, Paul H.'s argument for using DNS
> names in CAA was a good one and I can't see any advantage to inconsistency.
> It also makes it much easier to make any scheme work with a private CA.

Agreed.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 1 Aug 2013 12:43:01 -0400

> Validation happens only *after* all other certificate chain checks are

My point is that the people who were customers of Diginotar had to get new
certs quickly. The Dutch government has complained in several forums about
the way in which the Diginotar root was revoked. They had an entire
national port unable to function as a result.

If the root is revoked, the pins have to become inoperable and allow a user
to get a cert from any vendor.

Continuity of business is an issue here.

-- 
Website: http://hallambaker.com/

---

From: Yoav Nir <[email-masked]>
Date: Fri, 2 Aug 2013 00:05:51 +0000

On Aug 1, 2013, at 6:43 PM, Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Thu, Aug 1, 2013 at 12:30 PM, Chris Palmer <[email-masked]<mailto:[email-masked]>> wrote:

My point is that the people who were customers of Diginotar had to get new certs quickly. The Dutch government has complained in several forums about the way in which the Diginotar root was revoked. They had an entire national port unable to function as a result.

If the root is revoked, the pins have to become inoperable and allow a user to get a cert from any vendor.

To me this seems too hard for the browser. This is especially true if the pins were for a sub-CA rather than the root CA.

Yes, it is. That is what the backup pin feature is for, and why it is mandatory in the draft.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 7 Aug 2013 06:19:59 +0000

[with chair hat on]

Hi

So far, only Phil and Jeremy have been in favor of making this change. I don't think we have consensus for this change.

Even if others chime in now and say that they do want this change, I think we can't just ask administrators to list random names in headers or resources. For example, what string do you use for the bunch of trust anchors formerly known as "Verisign"?  Do you call it "Verisign"?  "VERISIGN"? "Symantec"? Are the Thawte public keys covered by the "Symantec" label? the "Verisign" label?  A wrong choice by an administrator (like getting your next certificate from a Thawte brand CA and expecting it to be covered by your "Symantec" pin) could lead to bricking the site.

That is not to say we must not do this, but we must not do this without a registry for CA strings. The go to body for registries at the IETF is IANA, but I don't think we've ever had an IANA registry for brand names. So unless we can get some body (the CA/Browser Forum ?) to create such a registry and provide a stable link that we can reference, I think this is a non-starter. Even with such a registry, I don't see consensus for this.

Yoav

---

From: Gervase Markham <[email-masked]>
Date: Wed, 07 Aug 2013 09:03:08 +0100

On 07/08/13 07:19, Yoav Nir wrote:
> Even if others chime in now and say that they do want this change, I
> think we can't just ask administrators to list random names in
> headers or resources. For example, what string do you use for the
> bunch of trust anchors formerly known as "Verisign"?  Do you call it
> "Verisign"?  "VERISIGN"? "Symantec"? Are the Thawte public keys
> covered by the "Symantec" label? the "Verisign" label?  A wrong
> choice by an administrator (like getting your next certificate from a
> Thawte brand CA and expecting it to be covered by your "Symantec"
> pin) could lead to bricking the site.

Without expressing an opinion on the question, it's worth noting that
this is already an issue with CAA, albeit that Symantec has to decide a
set of domain names (rather than simple strings) to represent them or
their brands. This was not a particularly difficult exercise for them,
they probably have the most roots and most brands, and it only had to be
done once.

So I'd suggest that it's not an insuperable obstacle.

> That is not to say we must not do this, but we must not do this
> without a registry for CA strings.

Or just require people to use "a domain name I control" rather than a
bare string, like CAA. No need for a registry.

Gerv

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 7 Aug 2013 02:28:38 -0700

On Tue, Aug 6, 2013 at 11:19 PM, Yoav Nir <[email-masked]> wrote:
>
> So far, only Phil and Jeremy have been in favor of making this change.

I'm in favor.

This is relevant to the .well-known URI vs HTTP Header discussion.
Pinning CA names would reduce HPKP size, making frequent sending of
headers more palatable.

More importantly, maintaining a list of key hashes for a set of CAs is
a complex undertaking.  I think many potential adopters will be scared
away, or will do it incorrectly (pinning keys they shouldn't, omitting
keys they should, not keeping the list current, and so on).

Consider that Google has offered preloaded key pins in Chrome since
May 2011 [1].  Since then it looks like ~100 organizations (apart from
Google) have signed up for preloaded HSTS.  Only 3 have signed up for
preloaded key pins.  That suggests we need to do more to make pinning
attractive.

Of those 3, one is a major website with a number of subdomains and
some content served over CDN.  It's pinning two sets of keys, one with
36 keys, one with 19.  The WG seems eager to dismiss this as a zany
"outlier" case.  I think that's a cavalier attitude towards one of the
best data points we have.  It's entirely possible that many websites
would have to construct lists of similar size and complexity (or
worse).

--

Finally, let's look into our hearts.  Imagine you had to construct an
HPKP header that includes a few popular CAs (Symantec, Comodo, and
GoDaddy, for instance).

You of course want to exclude irrelevant roots (like code-signing).
And revoked, expired, or soon-to-be-expired roots.  And
cryptographically weak roots (e.g. 1024-bit RSA).  And you'd need to
include enough root or intermediate keys to cover all cert paths all
browsers might construct for all certs these businesses might issue to
you over the pin timeframe.  (Taking into account the vagaries of root
ownership, cross-certification, AIA chasing, etc.)

And once you've figured that out, you've got to track it over time.
Keys could get revoked, expire, change hands, acquire or issue new
certificates, and get added or removed from root stores.

To me, this sounds difficult even for web PKI experts, and close to
unmanageable for anyone who isn't.

--

Anyways, I hope HPKP can offer websites a safe and easy route to
declaring CA pins.  I think that means improving usability.

If people think I'm wildly exaggerating the usability issues, or have
other proposals / explanations of how to solve them, I'd like to hear
that...

Trevor

[1] https://www.imperialviolet.org/2011/05/04/pinning.html

---

From: Gervase Markham <[email-masked]>
Date: Wed, 07 Aug 2013 10:35:51 +0100

> Pinning CA names would reduce HPKP size, making frequent sending of

Surely it would also significantly reduce flexibility?

At the moment, I can pin to a particular leaf, or a particular
intermediate, or a particular root, or to a set of any of the above. I
can decide where in the chain to pin depending on my analysis of the
cost/benefit. If we instead pinned to CA names, I would lose that
flexibility. Wouldn't I?

Gerv

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 7 Aug 2013 02:45:48 -0700

> Surely it would also significantly reduce flexibility?

I wouldn't remove key pinning.  Just allow pinning to CA names as well.

So an HPKP header could list keys both "directly" (by hash value) and
"indirectly" (by name).

Presumably the browser would have a table mapping names to key lists,
and would evaluate a site's cert chain by checking for an intersection
with all relevant keys in the pin (direct or indirect).

> cost/benefit.

I'm not suggesting disallowing that.

That sounds a bit complicated for most sites, though.  I'm imagining
that listing several trustworthy CAs, by name, would be a safer and
easier pin for most?

Trevor

---

From: Gervase Markham <[email-masked]>
Date: Wed, 07 Aug 2013 10:55:14 +0100

> with all relevant keys in the pin (direct or indirect).

Yes; this would need to be metadata associated with each cert in the
root store. It would need to be added when roots were added.

What happens if a CA requests a change to this mapping? This might
violate the expectations of some users as to which keys they were pinning.

Gerv

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 7 Aug 2013 03:14:10 -0700

> root store. It would need to be added when roots were added.

I was imagining a table which is indexed by CA names, and which maps a
CA name to a corresponding list of key hashes.  These hashes might
correspond to certs in the root store or they might not (e.g., they
might correspond to intermediates).

Only CAs which had "opted-in" and provided the requisite info to
browsers would be in the table.

> violate the expectations of some users as to which keys they were pinning.

When a pinned CA wants to introduce a new root, it would need to
update the mapping and wait for the update to propagate before using
the new root to sign certs.

When a pinned CA wants to remove a revoked or expired root from the
mapping, it should be able to do so without problems since browsers
would not construct cert paths that require this root.

Anyways, if users want to be pinned to a specific key, they should pin
to that key directly.  If they're pinned to a name, they're trusting
the CA and browser vendor to keep the mapping updated in a sensible
way.

Trevor

---

From: Gervase Markham <[email-masked]>
Date: Wed, 07 Aug 2013 11:47:15 +0100

> might correspond to intermediates).

While others disagree, I think that any attempt by browsers to include
information about intermediates in root stores will fail, because
intermediates change much more frequently than roots do. The
administration would be complex, and the update/outdatedness issues severe.

I would not predicate this scheme on browsers shipping a list of
intermediate hashes. And I would think you would want to get buy-in from
the major browser vendors that they are happy to take on the task of
maintaining such a table in order to get the gain of being able to
replace cert hashes with names.

> the new root to sign certs.

Right - but users who were trusting "FooCA" would now be trusting a root
they didn't know they were trusting.

What happens if two CAs merge, and the acquiring CA wants to have all
the roots of the acquired CA now under its brand?

> the CA and browser vendor to keep the mapping updated in a sensible

My concern is that this is an abstraction to make things work for people
who don't want to think too hard about PKI, but that the abstraction is
leaky, and will result in the violation of assumptions. I haven't spent
too much time thinking about this and I've already thought of a few.

Gerv

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 7 Aug 2013 04:12:54 -0700

> administration would be complex, and the update/outdatedness issues severe.

OK.  If pinning to roots is always preferable, the table would only
list pins to roots.

> replace cert hashes with names.

Absolutely.  The browser viewpoint is the most important.

> they didn't know they were trusting.

If you care about the specific keys you're pinned to, you should pin
to specific keys.

If you pin to "FooCA", you're trusting them to add and remove keys
from the named set.  You're giving up some control for convenience.

> the roots of the acquired CA now under its brand?

It adds them to the mapping for its brand.

> who don't want to think too hard about PKI

Yes!  But that's almost everyone.

> , but that the abstraction is
> leaky, and will result in the violation of assumptions.

Hmm..  Not sure what you mean, specifically.

Trevor

---

From: Gervase Markham <[email-masked]>
Date: Wed, 07 Aug 2013 13:10:41 +0100

> Hmm..  Not sure what you mean, specifically.

I mean, I think people who want to use pinning will expect the set of
certificates (and associated security practices) they are pinning to not
to change under their feet. This scheme means that they will. They might
also expect to define a pin and have it work everywhere HPKP is
supported, in exactly the same way. This scheme (due to client version
skew) means that it may not.

Gerv

---

From: "Jeremy Rowley" <[email-masked]>
Date: Wed, 7 Aug 2013 07:24:44 -0600

For pinning to a specific CA, the end user doesn't care which root they are
trusting.  They are indicating trust in an entire PKI.  In this case, I
think they expect the set of certificates to change, but have delegated this
trust to a set entity.  This is important for two reasons: 1) CAs can partly
mitigate the "too big to fail" routinely cited as a major weakness in the
industry by liming the number of certs signed to each intermediate/root and
2) enterprises utilizing a completely managed PKI solution can gain the
benefits of pinning, increasing the potential for adoption and use of
pinning.  

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gervase Markham
Sent: Wednesday, August 07, 2013 6:11 AM
To: Trevor Perrin
Cc: websec
Subject: Re: [websec] #58: Should we pin only SPKI, or also names

I mean, I think people who want to use pinning will expect the set of
certificates (and associated security practices) they are pinning to not to
change under their feet. This scheme means that they will. They might also
expect to define a pin and have it work everywhere HPKP is supported, in
exactly the same way. This scheme (due to client version
skew) means that it may not.

Gerv
_______________________________________________
websec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/websec

---

From: Gervase Markham <[email-masked]>
Date: Wed, 07 Aug 2013 14:27:05 +0100

Hi Jeremy,

> benefits of pinning, increasing the potential for adoption and use of

My apologies, but I am having difficulty tying your points (from "This
is important..." onwards) to what I was saying. Can you elaborate?

Gerv

---

From: "Jeremy Rowley" <[email-masked]>
Date: Wed, 7 Aug 2013 07:35:09 -0600

I suppose it wasn't directly related to your point.  I was simply emphasizing why pinning to a CA is an important option.  There are current CA-customer relationships that would benefit and use a pin to a CA over a root certificate.

-----Original Message-----
From: Gervase Markham [mailto:[email-masked]] 
Sent: Wednesday, August 07, 2013 7:27 AM
To: [email-masked]
Cc: 'websec'
Subject: Re: [websec] #58: Should we pin only SPKI, or also names

Hi Jeremy,

On 07/08/13 14:24, Jeremy Rowley wrote:
> For pinning to a specific CA, the end user doesn't care which root 
> they are trusting.  They are indicating trust in an entire PKI.  In 
> this case, I think they expect the set of certificates to change, but 
> have delegated this trust to a set entity.  This is important for two 
> reasons: 1) CAs can partly mitigate the "too big to fail" routinely 
> cited as a major weakness in the industry by liming the number of 
> certs signed to each intermediate/root and
> 2) enterprises utilizing a completely managed PKI solution can gain 
> the benefits of pinning, increasing the potential for adoption and use 
> of pinning.

My apologies, but I am having difficulty tying your points (from "This is important..." onwards) to what I was saying. Can you elaborate?

Gerv

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Gervase Markham
> certificates (and associated security practices) they are pinning to 
> not to change under their feet. This scheme means that they will. They 
> might also expect to define a pin and have it work everywhere HPKP is

---

From: Yoav Nir <[email-masked]>
Date: Wed, 7 Aug 2013 15:53:23 +0000

> browsers would be in the table.

I'm only wondering where I get a copy of that table and who maintains it. Having a different one maintained by each browser vendor IMO makes the Internet worse, not better. So do we have a volunteer to maintain it, maintain a stable link to it, receive updates from numerous new and old certificate vendors, and verify those updates with the browser vendors (so you can't register a new CA in the list if you aren't also trying to get in listed in the browser verndors' lists of trusted CAs.

BTW: it's OK to pin to trust anchors, but it also works to pin to the leaf public key (with a "spare" public key to be used in the next certificate). Surprisingly, pinning to intermediate CAs combines the worst of both options (out of your control like the CA, and changes often like the end entity)

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 7 Aug 2013 20:38:52 -0700

On Wed, Aug 7, 2013 at 8:53 AM, Yoav Nir <[email-masked]> wrote:
> I'm only wondering where I get a copy of that table and who maintains it.

CAs and Browsers would have to work that out.  I don't know what their
preferred coordination method would be.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Aug 2013 06:08:53 +0000

> preferred coordination method would be.

Yes. But they haven't so far. Since it's something that the CAs and browsers should work out, the obvious candidate organization is the CA/Browser forum. However, that organization contains neither all CAs not all browsers. It's easy to think that the set of browsers is {Chrome, IE, Firefox, Safari, Opera}, but there are dozens more. Relying on each one of them (including the small ones) getting information about labels from all CAs doesn't scale. Even more, the web server administrators need access to that list of labels and what it means.

So I suggest we don't include this now. Instead we make sure that whatever the result of #60 is, that HPKP is extensible. Later, when/if the CA/BF can get us a stable link to a list of labels, we can do a quick update document and add it then.

Objections?

Yoav

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 08 Aug 2013 21:18:22 +0100

Hi,

<no hats>

> preferred coordination method would be.

Hm, I did expect we could do the name pinning - if we want to do it -
without additional coordination at all for this. If you pin to the name
in the cert, this would only allow certs from this CA to be trusted for
this specific domain. As in the repository of the browsers as it is
today already. What did I miss here?

And I would strongly advise against any additional coordination
exercises as this makes the adoption more complicated and less likely.

Best regards, Tobias

---

From: Chris Palmer <[email-masked]>
Date: Thu, 8 Aug 2013 13:26:42 -0700

> That is not to say we must not do this, but we must not do this without a registry for CA strings. The go to body for registries at the IETF is IANA, but I don't think we've ever had an IANA regist…

With such a registry, I'd support it. It solves two problems:
ease-of-use for site operators, and (a distant second, but perception
matters) response header size.

But, setting up the registry is a probably-not-trivial job. Is anybody
interested in doing it? Is there buy-in from CAs (Phill?)?

---

From: Chris Palmer <[email-masked]>
Date: Thu, 8 Aug 2013 13:33:06 -0700

> cost/benefit. If we instead pinned to CA names, I would lose that

No, we could allow people to pin to either SPKIs or trust anchor set
names or any combination of the two. I don't think anyone has said
that it should be trust anchor set names *only*.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Aug 2013 20:42:01 +0000

> today already. What did I miss here?

If you go to https://www.iana.org, you get the following certificate chain:
 - *.iana.org
 - Go Daddy Secure Certification Authority
 - Go Daddy Class 2 Certification Authority

So without any registry, you can pin to "Go Daddy Class 2 Certification Authority". But the next time IANA needs to get a certificate (August 2016), even if they get it from Go Daddy, they might get it from the other root CA ("Go Daddy Root Certificate Authority - G2"), which signs with SHA-256, and who knows, by then they might have a new one, perhaps with ECDSA. As a customer, you talk to a vendor. Most customers don't know which TA is actually going to be used. In some cases (Symantec) there are very many of them.

Someone needs to map "Symantec" to a list of pins, and IMO that someone is neither the IETF nor IANA.

Yoav

---

From: Chris Palmer <[email-masked]>
Date: Thu, 8 Aug 2013 13:45:05 -0700

> they didn't know they were trusting.

The site operator had decided to trust FooCA to manage its operations
well and to issue certs well. If FooCA sets up a new root, that need
not change the operator's trust calculation. The explicit point of
this trust anchor set name mechanism is to allow site operators to not
care about the specific signing certificates FooCA uses. You seem to
be postulating a hypothetical site operator who wants to trust FooCA
generally, yet also wants to know about and trust only particular
issuing certificates that FooCA uses. That hypothetical site operator
sounds confused, to me: "Don't bother me with all these details; just
tell me everything."

> the roots of the acquired CA now under its brand?

Same thing. The site operator has chosen to trust FooCA. They can
trust FooCA to merge with only top-notch CAs (running their business
operations well), and continue pinning to the trust anchor set name
"FooCA". Or the operator can decide they hate the new merged business
entity, and switch to BarCA. Hopefully, they set a backup pin,
possibly to BarCA, and then they can do the switch quite quickly.
(They'll want a new backup pin, say QuuxCA, or a specific SPKI, or
whatever.)

> too much time thinking about this and I've already thought of a few.

That's how abstractions are: The leakiness is a feature. If it weren't
leaky, it wouldn't be an abstraction. That's why we would offer
pinning to both trust anchor set names and specific SPKIs.

---

From: Chris Palmer <[email-masked]>
Date: Thu, 8 Aug 2013 13:57:47 -0700

> Someone needs to map "Symantec" to a list of pins, and IMO that someone is neither the IETF nor IANA.

Insane idea (yes, I know it is insane): What if we chose not to have a
registry, and let people use substrings of issuer certificate
CNs/OUs/whatevers as trust anchor set names?

Obvious problems:

* character set encoding in the HTTP header vs. in the X.509
certificate: Welcome To Fun-Land, Where Fun Is Not Very Fun(TM)
* silly substrings, like "Go" matching both "...Go Daddy..." and
"...Google Internet Authority..." and "...Evil Bad People (Goats)..."
* substitution characters: should "Securite" match "...Sécurité Réseau..." ?

I'm sure we can all think of more problems...

---

From: Yoav Nir <[email-masked]>
Date: Thu, 8 Aug 2013 21:08:03 +0000

> CNs/OUs/whatevers as trust anchor set names?

Substring???  RegExp!!  :-)

> I'm sure we can all think of more problems…

Sure.

Symantec has done a lot of mergers and acquisitions, including of Verisign, which also did its share of mergers and acquisitions. So that now, Symantec has root CAs with brand names Symantec, Verisign, Thawte, and probably several others that I have forgotten. The chances of misconfiguration and bricking yourself with a new certificate are rather high.

Yoav

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 08 Aug 2013 22:36:04 +0100

<no hats>

Actually, I think the chances of bricking yourself are reasonably low/ok.

1. Consider that the CA must have the responsibility to inform the
website about any name changes of its organisation.
2. the name change of the cert only hits you when you get a new cert
from the organisation, as the name in your existing cert is still the
old one (old signing CA).
3. Before adding a new individual cert you need to phase out the old, by
using the dual pin (or dual name).

So I think the technical requirements are reasonably low to make this
work. And if people don't feel they are capable to do so, they can stay
with the normal pin to individual certs.

Just my 5cents, Tobias

---

From: Gervase Markham <[email-masked]>
Date: Fri, 09 Aug 2013 10:52:12 +0100

> CNs/OUs/whatevers as trust anchor set names?

That is a truly insane idea.

Let's pin to "DigiCert". That'll be OK, right?

Er, no:

https://blog.mozilla.org/security/2011/11/03/revoking-trust-in-digicert-sdn-bhd-intermediate-certificate-authority/

Gerv

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 10 Aug 2013 21:18:40 +0100

> bare string, like CAA. No need for a registry.

There are two questions here.

1) Should we introduce a level of indirection. i.e. should we only be
talking about pinning to bits that are actually present in the certificate
chain or should we support something more.

2) If the answer to (1) is to have indirection, who should maintain the
registry.

The main argument that I am making is that if the answer to (1) is 'yes'
then reuse the approach taken in CAA and do not introduce a new registry
because we do not want to maintain separate registries for different
purposes.

The secondary argument is that having established that the CAs are going to
have to decide on the domain names and scope etc. issues for CAA, the cost
of indirection is lowered.

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 10 Aug 2013 21:25:53 -0700

On Thu, Aug 8, 2013 at 1:26 PM, Chris Palmer <[email-masked]> wrote:
>> That is not to say we must not do this, but we must not do this without a registry for CA strings.
[...]
>
> With such a registry, I'd support it.

Do we need to do this now?

Could we just say:
 - The holder of a domain name is responsible for specifying the SPKIs
that it maps to.
 - How the domain holder communicates this to the UA is out of scope.

In the short term CAs and browser vendors could coordinate manually.
If this type of pinning becomes popular, more scalable mechanisms can
be evolved.

These mechanisms might be complex.  For example, CAs might publish
their key lists somewhere browser vendors could scan for them, and
there might be timing rules requiring changes be published X days in
advance, and requiring browser vendors to rescan for changes every Y
days.

But maybe it would be totally different.  Maybe we'd have to
experiment with multiple mechanisms.  And maybe named pinning won't
take off, so none of this is necessary.

So it seems best to separate this from HPKP, and advance HPKP now in a
way that lets us experiment with named pinning.  The hard work of
building a scaleable system for CA<->key mapping can be postponed
until it's necessary and we have a better understanding of
requirements.

Trevor

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 11 Aug 2013 12:34:24 +0100

Hi all,

<no hats>

A small question about pinning to names and uniqueness of "pinned names":
Under which conditions could the following attack scenario be a problem
and what would we do about it?

Domain A has bought a cert from CA-11 with the name "super safe" and
pins to the name instead of the cert.
CA-11 could be an intermediate for CA-1 with the name "uber super safe".
Which names could we pin to?
- the intermediate CA-1 and/or CA-11?

Now wondering whether the following is a problem:
attacker gains control over CA-2 (either through an attack or through
government influence) and issues a certificate for an intermediate
CA-11' with the name "super safe". CA-11' then signs its certs for
Domain A. If we pinned to its name, could an attacker now bypass
key-pinning protection by using certs from CA-11'?

What am I missing?
Under which conditions would this work?
   
Best regards, Tobias

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 11 Aug 2013 08:54:00 -0700

On Sun, Aug 11, 2013 at 4:34 AM, Tobias Gondrom
<[email-masked]> wrote:
> CA-11' with the name "super safe".

Yes, that's a problem.  Gerv also brought up the "DigiCert" name collision.

So using names as a "layer of indirection" to point to a set of
CA-declared keys seems better than trying to pin to names as they
appear in certs.

Trevor

---

From: Tobias Gondrom <[email-masked]>
Date: Sun, 11 Aug 2013 19:02:01 +0100

> CA-declared keys seems better than trying to pin to names as they

Thank you for the clarification.
In that case I would prefer not to pin to names. As the above scenario
is exactly the one we wanted to avoid in the first place.
We need to allow a domain to link to one specific cert or a specific set
of certs (like from one specified CA), and by this avoid that they are
exposed to risks by a breach of any other CA.

If we really need a to pin to a group of certs, maybe one other idea
might be to allow to pin to a top-node of a CA directly (but not
intermediaries as we would have the same attack scenario with them, too.)

Best regards, Tobias

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 11 Aug 2013 11:12:18 -0700

On Sun, Aug 11, 2013 at 11:02 AM, Tobias Gondrom
<[email-masked]> wrote:
> In that case I would prefer not to pin to names.

I'd prefer not to pin to X.509 Subject Names too.

What Phil, myself, and others are suggesting is pinning to a domain
name held by the CA as a way of indirectly pinning the set of SPKIs
under which that CA issues certificates.

Because this set may contain several SPKIs, and because it will change
over time, this seems a more user-friendly approach than pinning SPKIs
directly.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Sun, 11 Aug 2013 18:53:12 +0000

> over time, this seems a more user-friendly approach than pinning SPKIs

Hi Trevor. 

That would save us from a registry, but pinning is different from CAA. A CAA record is made to be read by either humans or humans aided by machines. 

If I advertise a CAA record for my domain with the FQDN "instantssl.com", then InstartSSL will issue me a certificate, probably in an automated process. If instead, I say "comodo.com", this might be flagged, but probably authorized in the end. If it says "Kommodo", eventually a human is going to look at it and decide what the intent was, perhaps with a question by email.

In key pinning, this decision is entirely for a computer to make. So the browser will need to untangle the mess of domain names that certificate vendors own due to mergers, acquisitions, and simple branding. Worse - without a centrally-maintained list different browsers might untangle it differently, and administrators will have to guess what works.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 11 Aug 2013 12:36:28 -0700

> In key pinning, this decision is entirely for a computer to make. So the browser will need to untangle the mess of domain names that certificate vendors own due to mergers, acquisitions, and simple…

CAs would tell browser vendors what names to use, and which keys those
correspond to.  I don't think browser vendors should try to infer this
on their own, as you're implying.

Having some sort of clearinghouse that aggregates info from CAs and
makes it available to browser vendors might be useful.  But this is
security-relevant info, so browser vendors might also prefer to query
this from CAs themselves.

So there are design decisions here that I'm arguing can be kicked down
the road.  In the short term (say the next year), we would be lucky if
3 browsers and a half dozen CAs wanted to experiment with this.  This
is small enough that it can be coordinated manually.

If named pinning proves useful and lots of other CAs and browsers want
to sign up, a more scaleable process can be designed then.

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Sun, 11 Aug 2013 21:21:57 +0000

Hi

All comments below are made as an individual.

> this from CAs themselves.

There is a third party here. The web site administrators need to set one of those strings in the key pinning data, so they should be able to obtain the correct strings. There may be only 3 browsers and half a dozen CAs that would want to experiment with this, but there may be a lot more web sites. The CAs could add it to their websites: "use 'ca.example.com' for RFC 7xxx key pinning". But I think we will get some pushback in either IETF last call or in IESG review if we try to kick it down the road.

> is small enough that it can be coordinated manually.

Experimentation is tricky. A pin is matched if one of the keys match, so if use the example from the draft:

   Public-Key-Pins: max-age=2592000;
       pin-sha1="4n972HfV354KP560yw4uqe/baXc=";
       pin-sha256="LPJNul+wow4m6DsqxbninhsWHlwfp0JecwQzYpOLmCQ="

The next time the UA connect it will check that the completed server cert chain has either of those pins somewhere in the chain.  Now let's replace the second pin with a named one. Assume that I have a certificate matching the first pin, but my next certificate is going to be from ca.example.com:

   Public-Key-Pins: max-age=2592000;
       pin-sha1="4n972HfV354KP560yw4uqe/baXc=";
       pin-named="ca.example.com"

When the UA connects again, the new certificate is there. The first pin no longer matches, so we need the browser to be able to verify that the new certificate matches ca.example.com. Once that is in some web sites, you can't stop the experiment. You'd have to go to each and every website that uses this pin and remove it. 

> to sign up, a more scaleable process can be designed then.

If I was assigned to do the SecDir review on this, I would push back on this.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Sun, 11 Aug 2013 14:39:40 -0700

On Sun, Aug 11, 2013 at 2:21 PM, Yoav Nir <[email-masked]> wrote:
> There is a third party here. The web site administrators need to set one of those strings in the key pinning data, so they should be able to obtain the correct strings. There may be only 3 browsers and half a dozen CAs that would want to experiment with this, but there may be a lot more web sites. The CAs could add it to their websites: "use 'ca.example.com' for RFC 7xxx key pinning".

Sure, the CAs would tell their website customers what to use.

> Experimentation is tricky.
[...]
> When the UA connects again, the new certificate is there. The first pin no longer matches, so we need the browser to be able to verify that the new certificate matches ca.example.com. Once that is…

It's easy to stop.  A browser that doesn't want to support named pins
could ignore any HPKP headers containing them.  If all browsers do
this, then HPKP is back to pure-SPKI pinning.

> If I was assigned to do the SecDir review on this, I would push back on this.

Why?

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Aug 2013 03:52:14 +0000

>> If I was assigned to do the SecDir review on this, I would push back on this.

Because that leave a part of the protocol that can't be implemented unless something happens that we don't specify.
Because only the big name browsers, who can get information directly from CAs will be able to implement this.
Because the list of acceptable strings would need to be updated often, and absent a registry, this means software update, and we shouldn't rely on those.
Because the chances of a misconfiguration resulting in a blocked site seem to me to be too high.

Yoav

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 12 Aug 2013 00:13:10 -0700

> Because that leave a part of the protocol that can't be implemented unless something happens that we don't specify.

Browser TLS already depends on coordination between browsers, CAs, and
websites that is outside the scope of RFCs like 5246.

It's not surprising that improving browser TLS might require
additional coordination between these parties.

This coordination could happen in various ways, and would probably
evolve over time.  It's also orthogonal to the on-the-wire protocol.
So it seems reasonable to leave it outside the current document's
scope.

> Because only the big name browsers, who can get information directly from CAs will be able to implement this.

Why would the CAs only provide this information to "big name
browsers"?  Why wouldn't they publish it?

In any case, we're fortunate that two of the "big name browsers"
represented in this thread are built on open source, so their actions
can be observed and learnt from, and their code reused.  If they work
with CAs to coordinate named pinning, it would be beneficial to the
public at large.

> Because the list of acceptable strings would need to be updated often, and absent a registry, this means software update, and we shouldn't rely on those.

Browsers already receive updates for many types of information (root
store updates, security patches, blacklists for malware and phishing
sites, revocation data, etc.)

> Because the chances of a misconfiguration resulting in a blocked site seem to me to be too high.

Seems quite the reverse to me.  The risk of HPKP misconfiguration
seems much greater if each individual website has to figure out and
track key pins for their CAs.

Trevor

---

From: Gervase Markham <[email-masked]>
Date: Mon, 12 Aug 2013 09:17:57 +0100

>  - How the domain holder communicates this to the UA is out of scope.

In other words "Don't set up a registry; just punt the problem and hope
something works itself out organically"?

> until it's necessary and we have a better understanding of

I think there will be problems with people not being protected who
expect to be, if you allow this sort of pinning into the spec but leave
entirely undefined the mechanisms for communicating what it actually
should mean when someone pins to a name.

Gerv

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 12 Aug 2013 09:11:53 -0700

> something works itself out organically"?

Yes.

If people hate this, someone should make a proposal for a registry:

 - Who maintains it?
 - How are requests to add or remove CA names authenticated?
 - Does the registry map CA names to actual keys?
   - If so, how are change requests authenticated?
   - What are the timing rules to ensure changes are propagated to
browsers as needed?
 - How can the registry be monitored and double-checked to avoid it
becoming a single point of failure?
 - Should these process details be defined in the HPKP spec or somewhere else?

> should mean when someone pins to a name.

Could you explain how these problems would arise?

I'm proposing CAs would coordinate with browsers, then inform their
customers (websites) which name to use.  A misbehaving CA could inform
its customers of a meaningless name, causing browsers to ignore the
pin.  But a misbehaving CA could violate its customers' security in
other ways.

Trevor

---

From: Gervase Markham <[email-masked]>
Date: Mon, 12 Aug 2013 18:04:24 +0100

> If people hate this, someone should make a proposal for a registry:

Or make a proposal to stick with the current spec, and not pin names :-)

> pin.  But a misbehaving CA could violate its customers' security in

They would arise via any of the obvious mechanisms this could go wrong,
e.g.:

* CA fails to communicate with (some subset of) browsers, perhaps the
small ones, leading to divergent behaviour

* Browser update is not universally accepted, leading to divergent behaviour

Say Foo CA merges with Bar CA, and issues an edict that from now on the
string "fooca.com" will include the already-deployed root, "Bar CA
Super-Secure". Six months later, after gnashing their teeth at the delay
that this process is introducing into their business, they start issuing
certs from "Bar CA Super-Secure" to Foo CA customers. A site,
naiveshop.com, is pinned to fooca.com, and buys one of these new certs.
All naiveshop.com's customers whose browsers are older than 6 months get
connection failures, and naiveshop.com can't easily detect that this is
happening, or to how many people.

Gerv

---

From: Yoav Nir <[email-masked]>
Date: Mon, 12 Aug 2013 18:50:09 +0000

> - Should these process details be defined in the HPKP spec or somewhere else?

As you've said, before this is for the CAs and browsers to come up with such a solution (assuming they want it, and I'm not hearing this from either the Mozilla people or the Google people on this list). CAs and browers. Now, if only there was some forum where both of these come together...

Joking aside, The CA/Browser forum is not currently in the business of running registries. IANA is, but I don't know how to specify in a draft an IANA policy that would include following mergers, acquisitions, and branding, and settling trademark disputes. Not do I have any reason to believe that IANA would be willing to do this. So unless the CA/Browser Forum agrees to take on this responsibility, and provide stable link for both machine and human readable mappings, I think this proposal should be shelved until we can find someone who will answer your questions above.

Yoav

---

From: "Jeremy Rowley" <[email-masked]>
Date: Mon, 12 Aug 2013 13:39:02 -0600

There are a couple of groups, in addition to the CAB Forum,  that may be
interested in hosting a registrar.  Let me check with them and get back to
you.  

Many of those questions can be readily addressed once a group or once
several groups have expressed a willingness to participate.  The one that
this working group is best poised to answer is whether the process details
should be defined here or somewhere else.  

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Yoav Nir
Sent: Monday, August 12, 2013 12:50 PM
To: Trevor Perrin
Cc: websec
Subject: Re: [websec] #58: Should we pin only SPKI, or also names

On Aug 12, 2013, at 7:11 PM, Trevor Perrin <[email-masked]> wrote:

>>> - The holder of a domain name is responsible for specifying the 
>>> SPKIs that it maps to.
>> In other words "Don't set up a registry; just punt the problem and 
>> hope something works itself out organically"?
> 
> Yes.
> 

As you've said, before this is for the CAs and browsers to come up with such
a solution (assuming they want it, and I'm not hearing this from either the
Mozilla people or the Google people on this list). CAs and browers. Now, if
only there was some forum where both of these come together...

Joking aside, The CA/Browser forum is not currently in the business of
running registries. IANA is, but I don't know how to specify in a draft an
IANA policy that would include following mergers, acquisitions, and
branding, and settling trademark disputes. Not do I have any reason to
believe that IANA would be willing to do this. So unless the CA/Browser
Forum agrees to take on this responsibility, and provide stable link for
both machine and human readable mappings, I think this proposal should be
shelved until we can find someone who will answer your questions above.

Yoav

---

From: "Jeremy Rowley" <[email-masked]>
Date: Mon, 12 Aug 2013 16:19:05 -0600

As would DigiCert.  Finding a home from the registry does not appear to be
difficult if CA pinning is supported.

Jeremy

-----Original Message-----
From: Rob Stradling [mailto:[email-masked]] 
Sent: Monday, August 12, 2013 4:13 PM
To: [email-masked]; 'Yoav Nir'
Cc: 'Trevor Perrin'; 'websec'
Subject: Re: [websec] #58: Should we pin only SPKI, or also names

Comodo would be happy to maintain this registry, if this WG decides that
it's required.

On 12/08/13 20:39, Jeremy Rowley wrote:
> There are a couple of groups, in addition to the CAB Forum,  that may 
> be interested in hosting a registrar.  Let me check with them and get 
> back to you.
>
> several groups have expressed a willingness to participate.  The one 
> that this working group is best poised to answer is whether the 
> process details should be defined here or somewhere else.
>
> Jeremy
>
> Behalf Of Yoav Nir
>> - Should these process details be defined in the HPKP spec or 
>> somewhere
> else?
>
> As you've said, before this is for the CAs and browsers to come up 
> with such a solution (assuming they want it, and I'm not hearing this 
> from either the Mozilla people or the Google people on this list). CAs 
> and browers. Now, if only there was some forum where both of these come
together...
> running registries. IANA is, but I don't know how to specify in a 
> draft an IANA policy that would include following mergers, 
> acquisitions, and branding, and settling trademark disputes. Not do I 
> have any reason to believe that IANA would be willing to do this. So 
> unless the CA/Browser Forum agrees to take on this responsibility, and 
> provide stable link for both machine and human readable mappings, I 
> think this proposal should be shelved until we can find someone who will
answer your questions above.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by
replying to the e-mail containing this attachment. Replies to this email may
be monitored by COMODO for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no
liability can be accepted and the recipient is requested to use their own
virus checking software.

---

From: Rob Stradling <[email-masked]>
Date: Mon, 12 Aug 2013 23:13:05 +0100

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: "Ryan Sleevi" <[email-masked]>
Date: Mon, 12 Aug 2013 15:53:13 -0700

>  Or make a proposal to stick with the current spec, and not pin names :-)

+1 to not pinning names.

>  happening, or to how many people.

To echo Gerv, I think there are a number of real and practical problems to
the idea of pinning to names that make this even more error prone in
practice than pinning to SPKIs.

The most obvious one is how to distribute updates to names such that they
are universally accepted/recognized? An SPKI is an unambiguous identifier,
but a named layer of indirection creates issues, especially if names are
re-used (which is their whole value over SPKIs - is that they CAN be
reused for different sets of pins over time).

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.

This is independent of mergers - CAs that are issuing new intermediates,
or deprecating old roots, etc.

You also create an assumption that "User Agent == Root Store", which is
NOT a universal. There are a LARGE number of UAs (typically, smaller ones)
that do not operate their own root store, and even one of the most popular
UAs does not operate a root store across all their supported platforms. In
this situation, roots may be added/removed from the root store on a time
frame different from modifications to this proposed 'CA name list', thus
creating interop issues like the one Gerv highlighted.

Support for SPKI pinning relies on no other infrastructure - whether it be
the registry or the update mechanisms - and can actively be shown to work
in practice. The existing failure modes discussed in
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-08#section-4
highlight the need to balance usability with security, and the trade-offs
involved.

Adding two or three more parties into the pinning infrastructure seems to
trade security, add complexity, and not actually provide real benefit to
usability, because it still allows pin skewing, but of a different nature.

To me, this represents a similar attempt to create another situation like
the Public Suffix List ( http://publicsuffix.org/ ) - well intentioned,
and certainly valuable, but easily opening up a whole host of new security
and deployment issues.

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 12 Aug 2013 17:53:07 -0700

> Or make a proposal to stick with the current spec, and not pin names :-)

Sure.  But then I'd also like to hear an argument for how this style
of pinning could solve its usability problems and become widespread,
given that Chrome's preloaded version of this attracted only 3 users
in 27 months.

> small ones, leading to divergent behaviour

Well, either a popular CA communicates its key list to browsers, or it
communicates it to the (thousands? millions?) of websites that would
like to be pinned to that CA.

There's a coordination problem either way.  So pointing out that
browser/CA coordination is a hassle and has some failure modes doesn't
seem a compelling argument against it, given the alternatives.

> happening, or to how many people.

Coordination between browsers and CAs would have to involve timing
rules.  A browser who has not updated a name/key mapping after some
period of time would have to stop using it, just as browsers stop
using preloaded pins if they're too old.

Trevor

---

From: "Jeremy Rowley" <[email-masked]>
Date: Mon, 12 Aug 2013 22:22:56 -0600

The problems with pinning a CA are similar to problems with pinning a SPKI.
Eventually, the browser needs updated pinned information.  CA pinning shifts
coordination of this update from the Website-Browser to a CA-Browser
communication.  

Permitting CA pinning allows an entity to essentially delegate certificate
decisions to single CA entity.  The usability problems are somewhat resolved
(although not eliminated) because the entity no longer needs to figure out
exactly which keys should be pinned.  Management can adopt a policy to only
use fooCA and then pin that CA, eliminating the need to try and coordinate
all the people responsible for making a decision and making the solution
easier for management to understand than a presented set of SPKIs.   

Jeremy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Trevor Perrin
Sent: Monday, August 12, 2013 6:53 PM
To: Gervase Markham
Cc: websec
Subject: Re: [websec] #58: Should we pin only SPKI, or also names

> Or make a proposal to stick with the current spec, and not pin names 

Sure.  But then I'd also like to hear an argument for how this style of
pinning could solve its usability problems and become widespread, given that
Chrome's preloaded version of this attracted only 3 users in 27 months.

>> customers (websites) which name to use.  A misbehaving CA could 
>> inform its customers of a meaningless name, causing browsers to 
>> ignore the pin.  But a misbehaving CA could violate its customers' 
>> security in other ways.
>

Well, either a popular CA communicates its key list to browsers, or it
communicates it to the (thousands? millions?) of websites that would like to
be pinned to that CA.

There's a coordination problem either way.  So pointing out that browser/CA
coordination is a hassle and has some failure modes doesn't seem a
compelling argument against it, given the alternatives.

> Say Foo CA merges with Bar CA, and issues an edict that from now on 
> the string "fooca.com" will include the already-deployed root, "Bar CA 
> Super-Secure". Six months later, after gnashing their teeth at the 
> delay that this process is introducing into their business, they start 
> issuing certs from "Bar CA Super-Secure" to Foo CA customers. A site, 
> All naiveshop.com's customers whose browsers are older than 6 months 
> get connection failures, and naiveshop.com can't easily detect that 
> this is happening, or to how many people.

Coordination between browsers and CAs would have to involve timing rules.  A
browser who has not updated a name/key mapping after some period of time
would have to stop using it, just as browsers stop using preloaded pins if
they're too old.

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 12 Aug 2013 23:40:35 -0700

> reused for different sets of pins over time).

Names are also smaller, and easier to configure, review, and debug
than lists of hash values.

> multiple different sets of SPKIs.

Browsers would need to stop using name->key mappings that aren't
current (say, more than 30 days old).

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

> NOT a universal.

I wasn't assuming that.  I was assuming CAs would publish key lists
that are sufficient to work with all browsers and browser root stores.

(They will need to do this regardless of whether these lists are used
by websites for SPKI pins, or by browsers for named pins.)

> There are a LARGE number of UAs (typically, smaller ones)

If a website is publishing SPKI pins, it will have to deal with the
complexities of varying browser root stores and path construction by
itself.  I.e., the website will have to publish an HPKP header that
takes into account all possible certificate paths all browser might
construct for all certs it might use during the pin lifetime.  This is
complexity intrinsic to trying to pin cert chains.  It's not caused by
named pins.

But with named pins, we could move this complexity from being an issue
for website deployers to an issue for browser/CA coordination, who are
better equipped to handle it.  This seems like an argument *for* named
pins, rather than against it.

> usability, because it still allows pin skewing, but of a different nature.

I think the usability benefit of having a mostly-static HPKP header
listing a few well-known brand names vs. a fluctuating list of many
key hashes, determined by factors most websites don't understand and
have little visibility into, is pretty obvious.

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.

I could plausibly imagine it becoming a best-practice for websites to
do CA pinning, even if it's fairly broad pins to sets of popular CAs.

I have trouble imagining this level of adoption with HPKP in its current form.

Trevor

---

From: Trevor Perrin <[email-masked]>
Date: Mon, 12 Aug 2013 23:43:16 -0700

On Mon, Aug 12, 2013 at 9:22 PM, Jeremy Rowley
<[email-masked]> wrote:
> decisions to single CA entity.

Or multiple CAs.

I think many sites would be well-served by pinning to several CAs.
This would yield a very safe pin with minimal vendor lock-in and with
protection from catastrophes like a CA being delisted or going out of
business.

With SPKI pinning, this multiplies the size of the HPKP header and the
number of CA key lists the site has to track.  That's a big reason I'm
pushing for a more manageable approach.

Trevor

---

From: Gervase Markham <[email-masked]>
Date: Tue, 13 Aug 2013 10:42:53 +0100

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

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.

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

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.

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

> websites would choose to include them into pins.

Can't CA's help in the current system? "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".

Gerv

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 14 Aug 2013 10:20:17 -0700

> the question is whether those advantages are worth it given the

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.

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

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

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

> requirement that they track the goings-on in the CA industry seems not

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.

> 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

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 14 Aug 2013 17:31:10 +0000

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

Sure, we can.

> "critical", so that an HPKP header is ignored if these new directive

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.

> security holes will be unpatched, blacklists and revocation data will

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.

> 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.
> when we've got more experience.

+1

---

From: Gervase Markham <[email-masked]>
Date: Thu, 15 Aug 2013 00:44:46 +0100

> deprecating old roots MUST get incorporated into website pins somehow.

Perhaps this is the point of disagreement.

I would expect CAs to offer appropriate pinning advice with
certificates, probably in the form of "paste this into your HPKP
header". Once a cert is in use and pinned, no further changes to those
pins need to be made. No matter what happens to the CA's business, as
long as the root and intermediate you are using are still valid (and,
absent a CA breach, they will be - no CA sells certs which use roots and
intermediates which expire before the cert finishes its lifetime), you
don't have to worry. When you get a new cert (renewal), you'll get
updated pinning advice.

If you have pinned a backup provider, you will no doubt have sought
similar pinning advice from them. There is more of a risk that this
advice will need to change at a different time from you changing your
cert, but that's OK, because you can change this stuff as much as you
like and all you have to do is wait for caches to empty (30 days?).

Gerv

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 15 Aug 2013 01:20:18 -0700

On Wed, Aug 14, 2013 at 4:44 PM, Gervase Markham <[email-masked]> wrote:
> pins need to be made.

So you're expecting sites to edit their HPKP header on every cert
change?  In that case I'd expect them to pin their end-entity key (see
reasons below).  I believe they'd have to edit the HPKP header twice:
 * Add their next end-entity key to the HPKP header
 * Wait for time T (where T is sufficient for all older pins to expire)
 * Switch to certificates with the new key
 * Once the switch is complete, delete the old key from the HPKP header

Sound right?

> No matter what happens to the CA's business, as

In a strict sense I don't think this is true.  You're assuming every
end-entity cert "uses" a single root, which is constant for the
lifetime of the cert absent a CA breach.

But HPKP pins are checked against the browser-constructed cert path,
which might contain intermediates and roots different from what the
website sent, or thinks its "using".

Example:  You pin what you think is the root cert of your current
certificate.  3 months later the intermediate is upgraded to a root in
the browser's trust store, or becomes cross-certified by a different
root.  Your pin fails, as the browser no longer constructs paths that
use the pinned root.

See Ryan's explanation of AIA chasing for more on this [1].

While pinning the end-entity's immediate-parent intermediate doesn't
have this problem, I don't see that it has any advantage over pinning
the end-entity key directly.

> like and all you have to do is wait for caches to empty (30 days?).

Well, you *can* change your HPKP header as much as you like, but do
you want to?  If you pin several CAs, and find yourself having to edit
the HPKP header multiple times a year, isn't that kind of a hassle?

My point was not that it's impossible for websites to track CA key
lists, just that it would be more user-friendly if they didn't have
to.

Trevor

[1] http://www.ietf.org/mail-archive/web/websec/current/msg01425.html

---

From: Gervase Markham <[email-masked]>
Date: Thu, 15 Aug 2013 09:30:43 +0100

On 15/08/13 09:20, Trevor Perrin wrote:
> change?

No; it's quite possible that the advice on renew would be "keep the same
pins".

And I'd expect the CA to talk about the trade-offs with the customer
before offering their best advice for the customer's situation.

>  * Once the switch is complete, delete the old key from the HPKP header

Pinning to an end-entity key is indeed more work. I suspect that for
most sites, the best trade-off will be pinning to two or three roots,
one from each of two or three different CAs, where the CA has told them
"yes, we issue certs from this root for sites like you, and will
continue to do so for the forseeable future".

> website sent, or thinks its "using".

That is true; however, a CA should be aware of the possible different
constructible paths, and provide pinning advice which takes them into
account.

> root.  Your pin fails, as the browser no longer constructs paths that

In this scenario, you seem to have failed to consult your CA for advice
on how best to pin to their chain :-)

> lists, just that it would be more user-friendly if they didn't have

In the sense you are discussing, I agree an alias is less precise, and
therefore more user-friendly. As I said previously, aliases are not
_all_ bad.

Gerv

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 15 Aug 2013 02:08:59 -0700

> No; it's quite possible that the advice on renew would be "keep the same

OK.  So you're expecting sites to request a new cert at least T days
prior to their existing cert expiring (where T is the length of time
needed for extant pins to expire).

The CA will inform them whether any new keys need to be added or
removed to the HPKP header, based on knowledge of their previous
header.

If new keys need to be added, the site will then go through an update
process like I described before:
 * Add the new keys to the HPKP header
 * Wait for time T (where T is sufficient for all older pins to expire)
 * Switch to new certificate
 * Once the switch is complete, delete any old keys from the HPKP header

Is this right?

> Pinning to an end-entity key is indeed more work.

Pinning to an end-entity key requires an update process on every key change.

Pinning to root keys requires an update process less frequently.  But
the process is of similar complexity.

> I suspect that for

I suspect most sites would prefer to pin more CAs, for safety's sake.
But I could be wrong.

It would be be nice if each CA is able to indicate a single key for
the customer.  But I'm not sure if that's feasible or excessively
risky.

> constructible paths, and provide pinning advice which takes them into

Sure.  But how paths for a *single* cert are constructed can change
over time, independent of new cert issuance, which you're not
accounting for.

> on how best to pin to their chain :-)

No, they gave you correct advice at the time of issuance.  The root
key pin was sufficient.

But things changed (due to, say, merger or business relationship
change between CAs).

Trevor

---

From: Yoav Nir <[email-masked]>
Date: Thu, 15 Aug 2013 15:19:46 +0000

> needed for extant pins to expire).

That would require either the sites to buy more certs than they need (and have overlapping certs) or the CAs to issue future certs (notBefore date T days in the future) and commit to the pinning data being valid for (validity_period + T). Not rocket science, but somewhat error prone.

OTOH if the site administrator pins the EE public key, they don't need to involve the CA at all. They just need to generate the key pair (or the certificate request) T days in advance, and add the new pin to the HPKP header/resource.

If someone were to ask me what a good pinning policy would be, I would say that they need three pins most of the time:
 1. for the EE certificate
 2. for the current root CA
 3. for some other root CA (that you trust)

If the EE certificate is compromised, you issue a new one from the current root CA, and update the pin.
If the CA gets compromised, you issue a new cert from the backup root CA and update the pin (also with a new backup)
T days before expiry, you generate a certreq, and add the new public key as a fourth pin until you change the certificate. 

The pinning idea became cool because static pinning caught the Diginotar breach. A policy like this would detect fake certificates (as long as Diginotar was not your primary or backup CA).

If CAs publish pin data on their website and guarantee that they will put any change on their website at least x days before the change takes place (90 days?) this kind of policy would work, but it would require administrators to check monthly both their primary and backup pins, otherwise the recovery plan above won't work.

Yoav

---

From: Tobias Gondrom <[email-masked]>
Date: Thu, 15 Aug 2013 16:37:57 +0100

> If CAs publish pin data on their website and guarantee that they will put any change on their website at least x days before the change takes place (90 days?) this kind of policy would work, but it…
Actually the CA could also use an email push service instead of or in
addition to the website publication.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 15 Aug 2013 16:16:08 +0000

> addition to the website publication.

They could, but occasionally the contact person at the customer's is someone who's left the company. Also, while the primary CA has your address, the backup CA has no idea that it is the backup CA. But yes, a link with "sign up for email updates regarding pinning data" would work.

Yoav