comparison with other stored security state mechanisms [was: Re: Sharing Trust Policy between Crypto Libraries]

[Stef Walter]

On 02/14/2013 09:36 PM, Ryan Sleevi wrote:
> On Wed, Feb 13, 2013 at 10:26 PM, Stef Walter <stefw at redhat.com> wrote:
>> On 14.02.2013 00:46, Ryan Sleevi wrote:
>>>
>>> I would discourage the notion of 'stapled extension' being used to
>>> store user overrides. The reasons for failures to a cert can not
>>> always be expressed as issues with end-entity certificates - for
>>> example, it may be due to chaining policies associated with the
>>> constructed chain, in which case, you don't want to override the leaf,
>>> you want to override the intermediate - but only in the context of
>>> that particular server.
>>
>>
>> What's the real world use case for that?
> 
> As a browser vendor, we see a variety of errors caused by the
> intermediates involved - from 'simple' errors like an intermediate
> being expired to more complicated errors, like the aforementioned
> policy violations (moreso when looking at the US FBCA and improperly
> configured intermediates).
> 
> Overriding the leaf is done in the context of "As long as this (set)
> of errors is consistent, and this (chain) is consistent, override the
> error" - it's not strictly on leaf, nor does it bypass any arbitrary
> error.

Interesting. But also very intricate with arbitrary and changing
requirements. Realistically this is not something we can expect all the
crypto libraries to implement in a consistent and reproducible way
unless they share an X.509 verification implementation.

>>> I think Apple's approach to this problem is better, so it's just worth
>>> thinking about:
>>>
>>> Each certificate in Keychain has an array of TrustSettings objects.
>>> Each TrustSettings is a dictionary of key/value pairs that
>>> (collectively) must match. Only one of the keys need be specified - if
>>> more than one key is supplied, then all criteria must match for the
>>> TrustSettings to apply.
>>>    - Policy (eg: SSL, S/MIME, X.509, Wireless, etc)
>>>    - Policy-specific data (eg: a hostname for SSL, an e-mail address for
>>> S/MIME)
>>>    - Requesting application (in this case, a code-signing identity)
>>>    - Allowed error (a specific error code that may be overridden)
>>>    - Result (the effective result to treat a certificate that matches
>>> this policy)
>>>
>>> See the documentation at
>>>
>>> https://developer.apple.com/library/mac/documentation/security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/c/func/SecTrustSettingsCopyTrustSettings
>>>
>>> This acknowledges several important use cases:  ....
>>
>>
>> Well, for what it's worth, this approach is necessitated by Apple's walled
>> garden approach. Take a look at the arbitrarily defined 'policies' which
>> defy generalization:
>>
>> http://www.opensource.apple.com/source/Security/Security-55163.44/sec/Security/SecPolicyPriv.h
> 
> Respectfully, I'm not sure why you jumped straight to attacking the
> business model as somehow being relevant to the security policy.
> 
> Microsoft (that is, pre-Win8 Microsoft) also approaches certificate
> validation as a set of policies - and has since the days of IE3. This
> recognizes that the PKIX path building algorithm is used by a variety
> of applications for a variety of purposes.

Fair enough.

> It may be that you're *only* thinking of this in the context of
> SSL/TLS as used by a user agent to communicate with a web server - and
> that may have been a design space requirement I missed. But minimally,
> the needs of validation differ between doing 'simple' RFC5280
> validation, 'SSL/TLS' validation (which includes things like checking
> EKUs and hostnames, among others), and things like EAP-TLS validation.
> I imagine that as Red Hat/Fedora pursue the crypto consolidation,
> other 'types' of verifications will emerge (notably, IPSec, which has
> its own set of EKUs and policies).
> 
> I agree, ontologically the classification is hard, and if it means
> that we simply constrain the problem to the set of problems facing
> 'browsers', that's reasonable - but we should at least be aware of the
> different needs of applications and how they are (or are not) being
> addressed.

Yes we should better define exactly the problem we are trying to solve.
Part of the problem is that I haven't updated the document yet, after
all our discussion here, and the initial document was a rough brain
dump. I hope to do that soon.

The main problem we're trying to solve is that the current situation
with absolutely no sharing of trust policy between applications and
crypto libraries on Linux is untenable. It's something we need to solve.
We can solve it in two ways:

 * An incremental approach, such as using stapled certificate
   extensions.
 * A rewrite all the verification algorithms approach.

I'm unable to embark on the latter. The perfect is the enemy of the
good. What we have is so *bad* that we can't wait for perfect to
magically appear. It hasn't in the last decade and a half, although
there have been some attempts

I realize that even the former approach is difficult and time consuming.
And that there is a trade-off, using the former approach I agree that we
may not be able to cover every last of all the possible use cases and
strange aspects of X.509.

>> But the main problem with using this approach essentially necessitates a
>> complete rewrite of all certificate validation logic, and is not easy to
>> retrofit on existing crypto libraries. Likely this would be done in the
>> contect of combining all the X.509 certificate logic into a single
>> implementation and having the libraries call into it.
>>
>> That's a mammoth project, has been tried before, and far beyond my planned
>> level of time investment in this effort.
>>
>> The biggest benefit of using stapled certificate extensions for modeling
>> trust policy is that it can be retrofitted and/or implemented really easily
>> onto current certificate verification algorithms. While at the same time
>> giving consistency and the new abilities.
>>
>> In addition (with the tweaks brought up on this mailing list) it is exactly
>> the same anchor model documented in such RFC's such as RFC5914
> 
> For trust anchor management, yes. But you've introduced the notions of
> pinning leafs as part of a TOFU (eg: Mozilla's "remember exception"),
> and I'm trying to highlight that the problem space is not the same as
> the TAMP setup - unless you're explicitly marking the leaf as a TAMP,
> which throws out the rest of the verification model entirely (because
> you don't verify attributes on anchors).

Yes, that area has room for clarification and improvement, and Gabor has
done some good research here. I like the idea of using key pinning
concepts for TOFU, rather than using stapled certificate extensions.

But I realize that this cannot cover all possible use cases without
becoming so complex that it is no longer possible to retrofit into
crypto libraries.

> Regardless of the idealism, I think you will find, even with NSS, that
> this would require rewriting many applications, and from what I
> understand of the proposal (which may be mistaken), is not something
> that will likely prove to be 'easy' to retrofit onto libpkix (or the
> 'legacy' verification, which is still what Firefox uses). For trust
> anchor inputs, yes, but if the notion is to add overrides for
> intermediates, that's further messier (especially when layered with
> multiple sources for attribute overrides).
> 
>>
>>
>>> 1) "overrides" (pinned settings) may be contextual dependent on the
>>> usage/purpose of the certificate
>>> 2) "overrides" (pinned settings) may be contextual dependent upon the
>>> error (or SET of errors)
>>> 3) "overrides" (pinned settings) do not attempt to 'rewrite' the cert
>>
>>
>> Of course that the Apple concept does not cover key pinning, and in our use
>> cases would be limited to X.509. But again these need to be modeled pretty
>> differently.
>>
>> But again, I'm not super turned on by the idea of "rewriting everything" for
>> a baroque technology such as X.509. Personally I'd like to see us make X.509
>> work reasonably consistently, with perhaps enabling a few new commonly
>> requested trust policy use cases, and then invest our time in other upcoming
>> TLS authentication stuff.
> 
> I see. I think that's unfortunate, but it's helpful to know where you
> see the priorities are. I suspect this is something we would not be
> able to use for Chromium then.

There's definitely room for loading simple shared trust policy
information, and then overriding with Chromium specific policy that
cannot (yet) be shared.

In addition I'm not trying to provide stop energy for you and/or others
(listening or not) to go ahead and implement a perfect solution, with
shared verification X.509 implementation, and so on. Please do go ahead.
In fact I would be overjoyed if you were to pull it off, even if it
means this (or other) work would be superseded or discarded.

FWIW, much (most?) of Apple's security code is open source and could be
ported. In fact I looked at doing that a while back when thinking about
the problems of the multiple crypto libraries on Linux. But I got scared
away by the nearly million lines of code involved. Others may be bolder
than I.

>>> 4) [Not examined in depth] It also reflects a hierarchy of trust
>>> settings - User -> System [Admin Defined] -> System [OS defined].
>>
>>
>> On this last point, that's something Robert Relyea brought up, and in the
>> stapled certificate extensions there's a decent approach we can take with
>> stacking the sources of trust policy, including off machine sources such as
>> tokens.
>>
> I don't think this is true in practice, from having worked with
> systems that have initially tried this approach, but perhaps I've
> misunderstood your proposal. If you're proposing merging (user &
> system) settings, and having them both apply, then you can end up with
> distinctly different security properties than an either/or system.

I was thinking that the various sources are ordered in a stack based on
a priority. If trust policy information for a given certificate or host
pinning is present somewhere in the stack then that's where things stop.

Imagine the user source having a high priority. If trust policy
information is present about a certificate in the user source, then the
system source is not consulted. So it's an either/or system, albeit per
certificate.

Of course this may be flawed. If so, would be happy to hear details
about problems and complexity/use-case trade-offs involved.

Cheers,

Stef