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

[Ryan Sleevi]

On Thu, Feb 14, 2013 at 2:33 PM, Stef Walter <stefw at redhat.com> wrote:
> 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.

Certainly - and to highlight, I was not suggesting we need to get
things 'perfectly'. If anything, I think we'd be quite happy to see
the problem space constrained to the "HTTPS" use case (since that
certainly meets our needs). If anything, my use cases were meant to
show how broad the field is when trying to attempt a truly generic
solution is/needs to be, to make sure that we're solving the "right"
problems. Certainly, on Linux systems, getting buy-in from libraries
is 'hard', so it's perhaps much more helpful to solve the immediate
problems *well*, *now*, and then worry latter about the broader class.

FWIW, and primarily as an aside, I would be over the moon if there was
a common certificate validation library for Linux, so that we could
avoid situations like
https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html
. That would make managing trust all the more easier, because it fits
into the same problem domain. Even if the *actual* crypto was handled
separately/pluggably (gnucrypt, nss, openssl, etc), the notion of a
common API for cert validation would be a wonderful step forward for
security. But, as you note, that really is a different problem.

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

Sorry, I realize in re-reading that my comments may have come off
wrong. What I was trying to say is that the "problem" of X.509 is one
that we browsers are going to be 'stuck' with for at least another
decade, even if there is some new and magical system that solves all
of its problems. That's why the problems of X.509 (and of PKIX) are by
far the most important ones for us - and making sure solutions are
usable in that space is important.

Alternative TLS authentication is certainly interesting, but because
it's not going to help or change the vast majority of existing sites,
the investment into trust policies related to it doesn't really have
much payoff.

Hopefully that makes it clear that it's much less negative than it may
have sounded at first.

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

This brings forth the classic question of system administration: If
the System (OS) says "Trust X", but the System (Admin) says "Do not
trust X", and the user says "Trust X", what's the (effective) trust
policy? The Sys Admin would like the answer to be "Do not trust" -
after all, they are the administrative role for the system.

Conversely, in a world where the System (Admin) says "Trust X", and
the user wants to say "Do not trust X", then it seems desirable that
the more restrictive policy is applied.

I don't have a good solution here, but there are several, and that was
the problem that I was trying to articulate.