On Thu, April 24, 2014 12:01 pm, Ivan Ristic wrote:
> On 23/04/2014 19:34, Ryan Sleevi wrote:
> > On Wed, April 23, 2014 1:31 am, Ivan RistiÄ wrote:
> >> 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
> >>
> >
> > 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.
>
> 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.
>
>
> > Cheers,
> > Ryan
> >
>
> --
> Ivan
>
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.
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
