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

[Michael Richardson <[e-mail]>]

Hi Ben,
A long consolidate email.

I missed SAAG because of conflicts with gendispatch.
I watched the youtube yesterday, and read the thread last week, and I read
the NFSv4 thread just now.

First, I think that to first order, this is a quality of implementation issue.

Having said that, implementations are going to lack quality, and being able
to (in a NAFTA/CETA/TPP/etc. compliant government RFP) reference something
has great value.  The alternative is that someone with minimal clue procures
some things and they don't work well together, and the IETF NFSv4 spec gets
blamed.  NFSv4 is the converged storage system spec.  While many of us know
it is successful (and helped find the Higgs boson), many do not.

I think that the use case scenarios for NFSv4 are largely intra-entraprise
rather than inter-enterprise.   Scaling *down* to two systems is pretty
important. Being able to do it without external systems matters here.
And for this being able to pin things matters.
That is WHY SSH was so well received.
At that scale, you don't need to care what you pin, as if it changes, it is
because you did something.

At the >10 desktop scale where some technology like Kerberos is hard to
justify in terms of human learning resources, the use of either a private CA,
or a single public anchor for the server makes sense, and the pinning modes
that are described in the thread make sense to me.
It's not really bits on the wire, but:

  a) it may require new error codes to clearly articulate when the pinning is
     broken. This goes to comments during SAAG as to the need for well
     articulated APIs.

  b) while it is sometimes true that:
     "Modern TLS stacks allow for indicating that a non-root CA and
      even an end-entity (non-CA) certificate are considered to be trusted as
     trust anchors, and thus the pinning you desire can be implemented within
     generic PKI trust frameworks as choice of a single specific trust
     anchor"

     the way in which this done even in the so-called "modern" OpenSSL is
     pretty much a black art.
     While some applications like curl (and fetchmail) have figured it out,
     and mostly present this well, it's not universally done well.

The blob that I move (with human supervised integrity) from machine A to
machine B for the four pin cases described is not standardized.
This matters once an administrative interface is placed on top of it.
Whether that's a web UI, or a netconf YANG model.

I use NFSv4 within my LAN, where I authenticate with IP addresses, and the thing
that keeps me from using it from my laptop (vs SSHFS) is that I don't know
how to trivially do the right certificate exchange.
I'm sure I could figure out, but I'm not sure write a UI for it.

As you write:

> feel quite confident that putting the entire Mozilla root set in my trust
> store is the wrong thing to do for this purpose; the question I'm
> interested in asking relates to "what is the right thing for this purpose?".

so it seems that we ought to have some nomenclature that describes the
recovery cases that are important.

Yaron writes:
> Exactly! Daniel Migault and I published an RFC [1] on "identity pinning" in
> TLS 1.3. This is TOFU pinning seen as a second factor, where the first
> factor is PKI. It also happens to be very low maintenance and independent
> of certificate (EE and CA certificate) changes. This solution is especially
> useful for enterprise use cases, where certificate transparency doesn't do
> the job.

I think that there are two divergent types of pin, and there were allusions
which I missed in the saag meeting as to who is using the term in a different
way.   Yaron describes pinning as second factor, which assumes that the PKI
is minimally valid.  It guards, I think, against a different CA issuing a
name.   The pin is more of a configured name-constraint, I think, but I only
browsed that RFC very quickly.
The other kind of pinning assumes that the PKI does not reach known root,
or rather it configures a new trust anchor for the use of this API.
I gave a talk at INTC today about Enterprises and trust anchors, and I think
that this is very relevant.  Enterprises are mostly lost here.

In summary:
  I think that many non-HTTPS users of TLS would benefit from a common
  understanding of pinning.
  The HTTPS uses of the term are different, and are tied up in the
  WebPKI,CT,etc. uses.
  We probably need a few new terms.

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