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

[Gabor Toth]

>>>>> On Tue, 15 Jan 2013 12:18:52 +0100, Stef Walter <stefw at redhat.com> said:

> All very interesting. A few comments below. This really does bring up
> several good use cases to try and model.

> Since there is obviously a lot of new ideas and work being done in the
> area of key pinning and TLS trust in general, more than actually
> modelling the specifics of these things, we need to come up with a model
> that represents what we need, but is also extensible in the long run.
> Otherwise we'll end up designing one of these storage systems for every
> new idea and trust plugin that comes along.

Agreed.

> BTW, I agree with Simo that SQLite is going to be a rough choice when
> sharing information across security boundaries. When building this stuff
> we need to remember that most of the regularly modified key pinning
> information is specific to a user, and not the system. The system
> information tends to be updated infrequently.

Initially I was thinking of a single-user desktop use case, where every user
manages its own pinning database. Sharing this information for the whole system
can be considered in case of servers, although that brings up issues with
security boundaries and might not help much in case different services
communicate with different hosts anyway. I think we can focus on a single-user
use case for now.

> But in any case, those are implementation details and neither API nor
> part of the model.

Right.

> Although PKCS#11 has some ugly aspects, it does have an extensible
> object model, and using it allows us to plug into and interoperate with
> the various consumers of trust information already around (such as NSS
> and so on).

> But that's not to say there shouldn't be an additional or simpler API on
> top of it.

I think it makes sense to provide such an API. If we do that, the underlying
storage implementation would not matter that much, though. As the pinning
implementation would require additional code anyway, how would PKCS#11 be
advantageous for interoperability in the this case?

> FWIW, I'm not super sure about the focus on dialogs and UI. Any scheme
> which expects its users to play janitor or security guard on their own
> computer unfortunately won't get the widespread pickup desired.

It's not ideal, true, that's what these pinning protocols supposed to solve.
But until they're in place, which would take some time, it's still better to
have more security in exchange for more work the user has to do. Obviously this
is not something I would force on all users but offer it as an option for
security-conscious users. Also, if it's set up with reasonable defaults in a way
that only requires little user interaction, that would increase the potential
user base. Something like pin the root CA by default and only notify when that
changes would already help, and more restrictive settings could be applied as
desired.

>>> Public Key Pinning
>>> * The host name is the primary-key (in database parlance). Policy
>>> is retrieved about the host, including a possibly pinned spki/hash.
>> 
>> Instead of just the hostname, this could be the hostname+protocol+port
>> together, to be able to store different keys for different services of
>> the same host.

> Interesting. That's a key point. OOI, why did you define protocol as
> part of this? Wouldn't hostname+port be enough? Is it a nice to have, or
> do you think it's really truly part of the primary-key (so to speak)?

I would not assume everyone uses a single protocol, and this is what DANE does
as well (_443._tcp.example.com). Although I agree that it's not common to use
different certificates for the same ports on different protocols.

> So for key pinning, I've been thinking along the lines of defining
> something along similar lines to the stapled extensions.

> So for key pinning you would the 'peer' as a primary-key. One of
> the main forms for a peer is a hostname+port (and perhaps protocol).

> Then attached to that you would have a number of pinning extensions that
> define the details of the pinning. So far TACK you would define a TACK
> pinning extension, which would contain the relevant TACK information to
> be used with that peer. Each pinning extension would have a unique OID.

> The format of the different pinning extensions would be defined
> separately, perhaps in an appendix, although we could work through a few
> to make sure they work.

Also, the possibility for storing multiple pins for a peer should be considered,
although that could also be left to be defined by the pinning extensions.

> Similar to certificate extensions these key pinning extensions can be
> marked as critical or not. If one is critical it must be understood and
> respected in order for the key pinning to be used.

What's the purpose of this flag? These pinning protocols are more like
replacements and not enhancements to each other, I would imagine a priority
indication could work better here.

>>> Obviously these two trust schemes can be used together. In addition
>>> they could both share a blacklist of public keys.

> FWIW, correcting myself here ... the more I think about it blacklists
> are specific to the X.509 trust model. X.509's reliance on blacklists
> can be seen as the deficiency that these other mechanisms are trying to
> solve. Therefore we need not generalize the blacklist to cover key
> pinning. Key pinning is a form of whitelist, there are (and should be)
> ways to remove pins, and we need not confuse this with the concept a
> blacklist.

Agreed.

> I'll be working on a new specification with some of the above concepts.
> This first round of discussion has clarified a lot of issues.

OK, sounds good.

-tg