Subject: [websec] Clarify pin validation for hosts with multiple trust paths

From: Ivan Ristić <[email-masked]>
Date: Wed, 23 Apr 2014 09:31:38 +0100

In Section 2.6. ("Validating Pinned Connections"), there is this wording:

"To perform Pin Validation, the UA will compute the SPKI Fingerprints
 for each certificate in the Pinned Host's validated certificate
 chain, [...]"

It is assumed that there is only one validated certificate chain. In
practice, there could be multiple valid certificate chains, some with
pins, others without. It's possible that a UA will first process the
paths, select one deemed to be the "best", only after which the pins
will be examined. If the selected path is without pins, the connection
will fail, even though there might be another paths that could have been
used.

I think the specification should describe this situation, and instruct
UAs to try alternative (acceptable) trust paths in case of pin failure.

-- 
Ivan

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 23 Apr 2014 11:34:56 -0700

>  UAs to try alternative (acceptable) trust paths in case of pin failure.

Note that describing path *building* algorithms has largely been outside
the scope of most protocol work. The fact that there are multiple valid
paths - eg: via the chasing of authorityInfoAccess - has in fact been
contentious in other WGs (PKIX/TLS, for example) - in part because the aIA
is unvalidated, attacker-controlled data being processed by the client.

The exact behaviour of the UA's path building algorithm is equally one
that differs wildly between UAs (and notably, sometimes between the same
UA on different platforms).

The behaviour you describe as preferable (check-while-building) is
something that's been/being implemented in Firefox, while the behaviour
you dislike (check-after-building) is something that's been implemented in
Chrome. For Chrome, when dealing with different platforms' path validating
APIs, the check-after-building is the only implementation *possible* using
these APIs.

I don't think the check-while-building algorithm provides any more
determinism for clients than the check-after-building algorithm. For sites
that are implementing pinning, they have two absolute guarantees - the
SPKI of the EE cert, and the SPKI of the EE's signer - will always be in
the chain. Above that, the exact nature of what's valid - either with
check-after or check-while - is somewhat dependent on the applications'
trust store - and if you wish to pin at those levels or above, you need a
robust pin set. PKP-R-O provides a means to discover that pin set
proactively prior to pinning.

Cheers,
Ryan

---

From: Ivan Ristic <[email-masked]>
Date: Thu, 24 Apr 2014 20:01:36 +0100

> proactively prior to pinning.

OK. I get it; different approaches are taken by different UAs, and this
standard cannot resolve that.

The fact still remains that check-after-building approach could result
with pin failures if the "wrong" certificate in the chain is pinned
(e.g., the root). If the UA decides to use a different path (for
whatever reason), the pinning will fail. Perhaps the paths can also
change with time, making these problems even more dangerous.

If we accept that path building is outside the scope of PKP, then the
RFC should at least describe these problems and give strong advice to
either (1) pin the EE's signer and (2) do something else at own risk.

-- 
Ivan

---

From: "Ryan Sleevi" <[email-masked]>
Date: Thu, 24 Apr 2014 12:24:23 -0700

>  either (1) pin the EE's signer and (2) do something else at own risk.

Right, this has been the fundamental tension that others, such as Trevor
Perrin, have called attention to.

Different applications have different trust stores - this is, arguably, a
good thing (for example, more security conscious applications can move at
a quicker pace to deprecate insecure algorithms/configurations than a
generic, OS-level store can). Further, CAs can and do cycle certs - with
the transition to SHA-2, we are already seeing a variety of CAs who have a
variety of root certificates (RSA, ECC) x (SHA1, SHA2) that are all
capable of cross-signing the same intermediate.

There was the past discussion about whether or not it makes sense to pin
to a 'named entity', and leave it up to the UA to correlate that named
entity into a specific root. This was discussed in Issue 58, but the end
is that there isn't a good framework for naming here.

I don't agree that pinning the EE's signer is necessarily good advice -
CAs regularly rotate their intermediates (eg: for CRL partitioning), so
it's hard to suggest that's a good, long-term stable solution. Really, the
solution is for the site operator to coordinate with their CA and work on
recommended pinning practices for the CA's PKI. This would be easier if
CA's actually documented their PKI consistently, but sadly, my experience
is that most CA's repositories only contain the "current" view of their
PKI, and not historically-and-still-valid or trans-valid (to borrow Peter
Eckersley's term) certificate paths.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 24 Apr 2014 15:33:01 -0400

On 04/24/2014 03:24 PM, Ryan Sleevi wrote:

> it's hard to suggest that's a good, long-term stable solution.

just wanted to give real-world confirmation on this: with heartbleed i
know a lot of folks have done a lot of cert reissuance.  at least one CA
has re-issued certs in this context from a different intermediate CA
than the original cert was issued from.  Had the re-issuing site been
pinning to its immediate issuer, the re-issued cert would have been
rejected by pinning clients.

> Really, the
> recommended pinning practices for the CA's PKI.

I agree with this, and that CAs need to be much clearer (to both
subscribers and relying parties) about their planned infrastructure
transitions.

	--dkg