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

[Eric Rescorla <[e-mail]>]

It might be helpful to nail down our terminology here.

Traditionally, we have three main approaches to public-key based key
management:

- Manual configuration and/or TOFU (a la SSH)
- DNSSEC with something like TLSA
- Deferring to some set of CAs (PKI) [0]

As a practical matter, PKIs currently come in two flavors:

- Publicly verifiable certificates which are rooted in one of a set
  of commonly trusted CAs (generally WebPKI).
- Non-publicly verifiable certificates which are rooted in some other
  set of CAs (e.g., enterprise CAs).

If you want to be able to talk to any machine on the Internet and
you're using PKI [again, you could use DNSSEC/TLSA] then you need to
have publicly verifiable certificates. However, there are a large
number of such CAs and any of them can issue for a given name. This is
where pinning comes in, as a technique for restricting the CAs (or EE
keys) which can be used to authenticate a given name. Importantly,
pinning only *restricts* the set of keys which can be used with a
given domain; it doesn't expand it. IOW, you still need a valid PKI
cert. If you're just configuring a key and not using the PKI,
that's not pinning.

Pinning on the Web [RFC 7469] is now more than five years old and in
the intervening period, opinion has shifted, with people increasingly
believing that pinning was too brittle a feature to deploy safely.
For this reason, Firefox and Chrome have both deprecated pinning (I
believe that Safari and IE never had it). So, to the extent to which
there is a consensus, its that pinning is not a best practice.

I think there's a separate question of what one ought to do when
one does not need to connect to any machine on the Internet [1]. In
those cases, whether manual configuration or a private CA is most
appropriate seems to be a judgement call depending on how complicated
the deployment is. I don't know the RPC-over-TLS setting enough
to know what is best here.

-Ekr


[0] One can argue that DNSSEC is a form of PKI, but I've broken
it out for convenience here.

[1] You call out the special case where an app is talking back to
its own site:

   A banking mobile app
   surely should pin the bank's known CA, rather than leaving an enterprise
CA
   free to MITM a user's session, whereas something that wants to be part of
   the Web is largely forced to adopt the Web PKI.

I would make two points about this. As a practical matter, it's not
uncommmon for this kind of captive app to just use a generic WebPKI
certificate, so this isn't really that different from serving up
an HPKP header to a generic Web browser. Second, prior to HPKP being
deprecated, it was standard practice to exempt locally installed
CAs from pin checks because otherwise users would experience failures
on networks which had MITM proxies. It seems like a similar set
of considerations would apply in this case.















On Tue, Jul 28, 2020 at 12:13 PM Benjamin Kaduk <[e-mail]> wrote:

> Hi all,
>
> One of the agenda items for Thursday's SAAG session at IETF 108 is
> "Discussion on PKI vs. Pinning Applicability".  This is intended to be
> Security Area Advisory Group in its core meaning -- I want to get the sense
> of the IETF security community.  There are some draft slides for SAAG at
>
> https://www.ietf.org/proceedings/108/slides/slides-108-saag-chair-slides-pkipinning-bcp-72-00
> (starting at slide 33; note to self: change template to include slide
> numbers), and in true IETF spirit I'm hoping we can get a lot of it covered
> on the list in advance.
>
> As a lead-in, this topic came to mind due to a thread on the NFSv4 list,
> discussing the RPC-over-TLS work that's in IESG Evaluation.  A participant
> made the claim (see thread at
> https://mailarchive.ietf.org/arch/msg/nfsv4/SLTNqWbjE-H8JshLk0HwlwxArrI/)
> that certificate pinning is needed for RPC-TLS, and I did not have the
> impression that this was the consensus position of the IETF security
> community ... but I also don't have any data to support that impression
> (yet?).
>
> It's clear that there are benefits and drawbacks of both approaches,
> relating to scalability, ease of (minimal) deployment, key rotation, need
> for maintaining highly secure infrastructure to protect high-value secrets,
> how revocation is handled, whether or not having an enterprise CA is seen
> as a bug or feature, etc.  Similarly, there seem to be some use cases that
> naturally lean towards one strategy or the other.  A banking mobile app
> surely should pin the bank's known CA, rather than leaving an enterprise CA
> free to MITM a user's session, whereas something that wants to be part of
> the Web is largely forced to adopt the Web PKI.
>
> This leads to some questions that may be worth discussing (both here on the
> list and in-person on Thursday):
>
> Can we make a classification of what types of protocols are naturally
> suited for PKI scenarios and what types of protocols are naturally suited
> for pinning?
>
> If you're going to pin, how does it matter if you pin a (raw) public key, a
> self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root CA,
> etc?
>
> 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?
>
> Do we want all protocols that specify one to be usable with the other (and
> document it that way)?
>
> Is there utility in writing a document to cover any of the above topics?
>
> Thanks in advance for a lively discussion,
>
> Ben
>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>