Re: [saag] On PKI vs. Pinning (SAAG 108 preview)

[Michael Richardson <[e-mail]>]

Viktor Dukhovni <[e-mail]> wrote:
    >> Is there benefit in arranging for a description of the system where
    >> the ability to pin is just a degenerate case of a PKI, with a single
    >> trust anchor and no real hierarchy?

    > FWIW, I should mention that the DANE support in OpenSSL (since 1.1.0) is
    > really just support for verifying a certificate chain against a list of
    > EE and/or TA pins.  The pins need not come from DNS, and DNSSEC is not
    > required to use the "DANE" in OpenSSL.  How the application obtains the
    > pin values is not OpenSSL's concern.

    > The PKIX-TA and PKIX-EE pins are second factors, while the DANE-TA
    > and DANE-EE pins are bypass verification via the usual root CA
    > store, and use only the pins to validate the chain.

There are some terms here that I want to lift up:

1) PKIX-TA
2) PKIX-EE
3) DANE-TA
4) DANE-EE

I think that the "DANE" in (3) and (4) are not, (as is pointed out in by Viktor),
specifically DNS/DNSEC, but rather the point is that they aren't descending
from a *PKIX* trust anchor.

That there are four ways to pin seems consistent with other comments on this
thread.  It seems to me that having a short document that explains the
four methods would be a useful thing to do.  Are there more than four? Maybe.

    > Thus, for example, in Postfix the following all use the same underlying
    > "DANE" (really general-purpose pinning) API.

    > - The "fingerprint" security level that verifies the peer
    > against a static locally configured list of acceptable
    > certificate or public key fingerprints.

    > - The "secure" level with a local per-destination "tafile",
    > which pins acceptable (possibly intermediate) issuer
    > certificates or public keys.  The chain must be signed
    > by an issuer that matches one of the pins.

    > - The "dane" level, where the "pins" take the form of
    > dynamically obtained DNSSEC-validated TLSA records,
    > which can be a mixture of EE and TA pins.

These have different security properties, and maybe represent two additional
forms of pin.

    > So if an OpenSSL application wants to implement pinning that
    > either replaces or augments WebPKI validation, the code is
    > already there in OpenSSL, in the form of support for "DANE",
    > but perhaps it is not correctly "marketed".  It is a really
    > a fairly general framework for validating certificate chains
    > against a list of "pins" ("OR" rather than "AND" semantics,
    > success when any *one* of the pins works out).

Stephen Farrel mentioned the banking app that comes with a pin.
I think that such a an app would like to know that it is not getting through
due to Enterprise audit-based MITM, or National-Firewall MITM.
Of course, it could also be another attacker, and RFC7258 in many ways labels
the above as attacks.

Someone using that app might want to ask their bank about what kind of
pin they are using, and they might like to get back a clear answer.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-