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
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
