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

[Stef Walter]

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.

On 01/14/2013 08:50 PM, Gabor Toth wrote:
> The way it would work is to first check pinning information available
> through one of the proposed protocols (DANE/TACK/websec-key-pinning/etc).
> As it will take some time until these pinning protocols are widely
> used, it would fall back to a TOFU scheme, which also needs a local
> database for pinning settings of hosts. Such a database could be
> shared by the different pinning approaches.
> 
> As for the actual implementation of the database, one option is
> SQLite, which already implements a proper locking scheme for shared
> access across many applications, to facilitate frequent read/write
> operations. 

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.

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

> PKCS#11 would be another option, but not sure how
> libraries implementing it handle shared access. How does p11-kit
> handle this?

Well PKCS#11 is an API. Simultaneous access is supported (but not
necessarily implemented by all implementations).

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.

> The TOFU scheme would have a similar (but improved) functionality that
> the CertPatrol FF addon provides:
> 
> - When a certificate is not found in the database: depending on user
>   configuration, either pin the certificate right away (and show a
>   notification), or show a dialog box with information about the
>   certificate received from the server, which the user can accept
>   or reject. If the user is still in doubt, a notary service
>   could be consulted, like Convergence or Crossbear.
> 
>   It would be also configurable what to pin by default
>   (certificate/pubkey of: end entity/issuer CA/root CA), again,
>   depending on the security/annoyance level the user wants. A reasonable
>   default setting would have to be determined for this.
> 
>   The dialog would contain certificate information, something like
>   gcr-viewer, but emphasizing the most important parts of the
>   certificate better, and offer the following choices:
> 
>   - Accept: store the chosen pin settings for all hostnames the
>     certificate is valid for.
>   - Reject: close the connection and mark the public key as rejected,
>     so that at the next connection attempt it can be indicated that it
>     was rejected already. If there's an infrastructure in place for
>     managing blacklists, it could be added to that blacklist.
>   - Continue: continue with the connection, the dialog would be shown
>     again the next time when connecting to the same host.
>  
> - When a certificate does not validate according to the pin setting
>   for the host: show a dialog like above, but with information of both
>   the old and new certs, indicating what changed. In addition to the
>   reject and continue choices, provide two accept options: either
>   replace the previous pin, or add an additional pin, to accommodate
>   hosts using multiple certificates simultaneously with completely
>   different certificate chains.

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.

But that's orthogonal to modeling the trust policy storage.

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

> Right, but we can still have a look at the proposed specs and come up
> with a storage model that can accommodate the different approaches.
> Even if they're not complete yet, adding a few fields later would not
> be a problem.
> 
> For reference, the storage models for TACK and websec-key-pinning are
> defined here:
> 
> https://tools.ietf.org/html/draft-perrin-tls-tack-02#section-4
> https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.3.2

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

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.

As an example, there would be pinning extensions for these, which might
contain fields like the following (rough):

 * TACK [1]
   - Initial time
   - End time
   - TSK public key
   - Min_generation
 * Websec Key Pinning [2]
   - max-age
   - Pin Hashes
   - includeSubDomains
   - report-uri
   - strict
 * Pinned Raw Public Key [3]
   - subjectPublicKeyInfo

The formats of the pinning extensions might be defined in ASN.1,
although there's nothing that prevents them from being defined
differently for a given pinning extension if a more natural format is
available and makes sense.

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

> Also, a utility for managing stored trust anchors, blacklists, and
> pinning information could be shared as well. A functionality
> comparable to browsers' clear history function would be also needed,
> to be able to remove some pinned hosts from the store.

Right.

>> So in my opinion, these can be complementary, could live in the same
>> store (eg: as PKCS#11 objects), but we I don't think we should try to
>> shoe-horn them into the same concept and implement them the same way.
> 
>> I'll clarify this in the certificate trust policy document (and
>> perhaps rename it) to make it clear this isn't dealing with key
>> pinning. That's for later.
> 
> These two could be worked on in parallel, I intend to work on
> implementing the pinning part.

Cool.

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.

Stef

[1] https://tools.ietf.org/html/draft-perrin-tls-tack-02

[2] https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04

[3] http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-06