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

[Gabor Toth]

>>>>> On Fri, 04 Jan 2013 22:33:42 +0100, Stef Walter <stefw at redhat.com> said:

> I agree with the various posts that there would be value in sharing
> public key pinning information between implementations (especially
> when multiple implementations are working with the same protocol and
> hosts, ie: http).

Hi list,

having worked on the CertPatrol Firefox addon before, I have recently
started working on a system-level version of it, which intends to
implement pinning functionality available for all applications. I
found this list while looking into how this could be implemented, and
as I see you're discussing here topics relevant to this, and agree that
it makes sense to have a common approach for storing pinning information
for hosts.

What I envisioned is implementing a library that applications / TLS
libraries can use for additional certificate verification, and
possibly also provide it as an LD_PRELOAD library that hooks into cert
verification functions of TLS libraries, to make it useful even before
it gets wider support.

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

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.

To gain more insight on which certificates are valid for a host, each
certificate ever seen for the host could be stored, indicating which
are the active (accepted) ones, and storing first seen / last seen /
count seen values together with them. This enables users to only
accept a certificate after seeing it already a few times from
different locations, and also enables detecting multiple certificates
simultaneously used for the same host.

> As Daniel and Simo noted it seems that we should split out work on key
> pinning information from the certificate trust policy work. The two
> could share a store, be accessed in related ways, but the actual data
> and methods for retrieving it are very different.

Agreed.

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

>  * What you might call the 'trust policy' for key pinning is very
>    different from that for certificate chains.
>    * Key pinning includes concepts like: force-security-for-this-host,
>      use-one-of-these-keys-for-host, min_generations, max-age-for-pin,
>      when-was-key-last-seen, include-subdomains, and so on
>      (paraphrasing based on my basic grasp of the tack/pinning specs).

>  * The complete problem space is still being hashed out, and hasn't
>    really converged yet. Which is good, cool to see progress and
>    discussion, but hard to make sure we can model exactly what's needed.

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

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

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.

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

-tg