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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Jul 2020 12:13:31 -0700

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jul 2020 20:36:33 +0100

Hiya,

Good topic.

> suited for PKI scenarios and what types of protocols are naturally suited

FYI, in our survey of covid-tracing Apps most but not all
of them do pin. When those apps are uploading keys, it'd
not be good for that to be logged in an enterprise security
appliance. That seems to generalise to any applications
where the relevant entities would not like their data to
end up logged like that (by accident or design), and where
the application not working when behind a MITM is ok, or
where one can expect the application to be whitelisted by
such MITMs. ISTM that may be a fairly broad class of
applications, certainly enough to be of interest. I'd
guess some of the operators of MITMs might prefer to not
be able to see some of that application data too.

> self-signed non-CA cert, an arbitrary cert, an intermediate CA, a root CA,

Raw public key seems too much a foot-gun. Even with
pinning, you still need to depend on a CA for TLS, so
it seems to make sense to pin to your currently
preferred CA(s) plus one other independent CA. We've
seen that in at least one of the above apps.

I'd guess the choice of root vs. intermediate might
depend, not sure there's an obviously correct choice
for that, for all cases.

> anchor and no real hierarchy?

I don't get the question sorry.

> Is there utility in writing a document to cover any of the above topics?

I think such a document would be useful. If it doesn't
already exist then doing that as an informational RFC or
BCP would be useful. If one exists already that's good
enough then pointing at that may be fine.

Cheers,
S.

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Jul 2020 12:42:35 -0700

Hi Stephen,

Thanks for the quick response :)

> be able to see some of that application data too.

There does seem to be something significant here, yes.
I gave an example of a banking app that would pin, and it's not entirely
clear to me whether "the application not working when behind a MITM is ok"
applies to such an example.  So there's some classification work left to
do.

> I don't get the question sorry.

Sorry for the clumsy description.  Basically, if you squint hard, you could
claim that at least some types of pinning are actually a PKI, just a
degenerate PKI.  E.g., in a PKI I have to pin at least one trust anchor as
the root of the PKI, and if that pinned trust anchor just happens to also
be the certificate directly used in the protocol, it's still a PKI, just a
tree of height one.
What's not clear to me is whether it's useful to force this kind of
thinking on anyone, or to try to insist that all pinning is just a
degenerate PKI.

> enough then pointing at that may be fine.

Thanks,

Ben

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jul 2020 20:49:18 +0100

> claim that at least some types of pinning are actually a PKI, just a

Ah gotcha.

ISTM more useful to treat pinning as an adjunct to whatever
PKI is used by the application that can be MITM'd and not
bother with pinning as a potential replacement for that
PKI. There's nothing wrong with an application being based
on it's very-own PKI of course, but seems less useful for
the IETF to try describe pinning for custom protocols where
we don't know the details.

Cheers,
S.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 28 Jul 2020 20:56:33 +0100

I'm a little surprised by this conversation. Why would SAAG want to support
a practice that flies in the face of everything we know about key
management?

On Tue, 28 Jul 2020 at 20:49, Stephen Farrell <[email-masked]>
wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jul 2020 21:09:17 +0100

> a practice that flies in the face of everything we know about key

Sorry if I gave the wrong impression. I agree with you
that pinning to application keys is a bad idea.

I do think there's a role for pinning to CAs that you
already gotta trust, as a way to fail rather than allow
a MITM, for the cases where that's better.

S

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 28 Jul 2020 20:14:30 +0000

I agree with this.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 28 Jul 2020 22:41:56 +0200

> suited for PKI scenarios and what types of protocols are naturally suited

How about some definitions here:

PKI = the set of root CAs is determined by one of a oligopoly of entities, based on CA/Browser Forum operations, where the entities aren’t really justifiable parties to the application?

Pinning = the set of root CAs is determined by the application, choosing a set of CAs specifically authorized for the application to aid in authentication?

Grüße, Carsten

---

From: Ben Laurie <[email-masked]>
Date: Tue, 28 Jul 2020 22:18:17 +0100

On Tue, 28 Jul 2020 at 21:09, Stephen Farrell <[email-masked]>
wrote:

> I do think there's a role for pinning to CAs

With you up to here.

> that you
> already gotta trust,

Why?

> as a way to fail rather than allow

Surely this is not what CAs are for? They're for succeeding rather than a
MITM, aren't they? That does suppose revocation that actually works (which
I would suggest is a more useful thing to work on than pinning).

Also, to be clear, pinning CAs is only deferring the problem - and, in
fact, without CA blacklisting, is not a great deal better.

Well. That escalated fast.

>
> S
>
> >
> > On Tue, 28 Jul 2020 at 20:49, Stephen Farrell <[email-masked]
> >
> > wrote:
> >
> >>
> >>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 28 Jul 2020 22:28:41 +0100

Hiya,

> Why?

Well, gotta is maybe a tiny bit overstated. I mean
the WebPKI CAs mostly for applications using TLS
and mostly HTTPS and where the application uses
the OS or browser root set or equivalent that's not
under the application's control. From the POV of
the person deploying such applications they kinda
do gotta trust those CAs and picking a subset of
those to which they pin doesn't make things worse
and can make things better. (Assuming CT logs too
of course.)

> Surely this is not what CAs are for? 

In theory. But once you can add a local enterprise CA
to the relevant root store then the application can be
MTIM'd. The application developer can't stop that,
but, via pinning to a CA, can cause a fail in such cases.

> They're for succeeding rather than a

I think it has sufficient utility in enough cases to be
worth documenting well. (Which could be done in the IETF
or elsewhere, but here'd be fine.)

> Well. That escalated fast.

Must be my neck is so thick already I no longer notice:-)

Cheers,
S.

---

From: Nico Williams <[email-masked]>
Date: Tue, 28 Jul 2020 16:43:02 -0500

> community ... but I also don't have any data to support that impression

Speaking as an implementor of credential orchestration systems for
corporate networks, the claim that NFSv4-over-TLS requires pinning is
wrong.  NFSv4-over-TLS, like most applications running over TLS, needs a
reasonable management solution for a) conveying trust anchors to relying
parties, b) certifying (here: server) keys in those PKIs.

In a corporate network I absolutely would not want TOFU.

But in any case, as long as the server software lets me configure a
credential, and the client software lets me configure TOFU (with or
without interactive confirmation), or pre-share keys.  I'm ok with the
RFC talking about pinning, though I would prefer it leave all details of
how the TLS server is authenticated to... the TLS spec.

Nico
--

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Jul 2020 14:46:23 -0700

Hi Ben,

I suspect that the quoted exchange might make some more sense in the
context of the full thread (e.g.,
https://mailarchive.ietf.org/arch/msg/saag/Md1Yiier0B0WXqN1suRU4r3p9zc/).
Consider, for example, the case where I am spinning up a TLS connection
between my NFS client and server and running NFS RPCs over it, and I need
to decide how to configure the TLS library to authenticate the peer.  I
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?".

Thanks,

Ben

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 28 Jul 2020 15:01:01 -0700

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.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 29 Jul 2020 00:58:45 +0000

Carsten Bormann <[email-masked]> writes:

>PKI = the set of root CAs is determined by one of a oligopoly of entities,
>based on CA/Browser Forum operations, where the entities aren’t really
>justifiable parties to the application?

While that's an accurate definition (if you substitute "WebPKI" for "PKI",
although for most of the world the two are the same anyway), good luck getting
anyone to admit that in a document :-).

Peter.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 29 Jul 2020 15:03:21 +0300

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.

Thanks,
	Yaron

[1] https://www.rfc-editor.org/rfc/rfc8672.html

On 7/28/20, 22:49, "saag on behalf of Stephen Farrell" <[email-masked] on behalf of [email-masked]> wrote:

    Ah gotcha.

    Cheers,
    S.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 29 Jul 2020 11:33:17 -0400

As is often the case, I agree with EKR here.

The point I would emphasize is that all of these options have the same
protocol footprint.  Regardless of where you root trust or how you
constrain it, the protocol needs to carry credentials that allow PKI-style
chaining/delegation.

--Richard

---

From: Daniel Migault <[email-masked]>
Date: Wed, 29 Jul 2020 12:03:34 -0400

> that pinning to application keys is a bad idea.

I am wondering what exactly is an application key. Is-it a sort of
self-signed certificate hard coded in the application or would a secret
generated by the application on  a per session basis is considered as an
application key.

> One issue I see is that we have CA we do not trust. I suppose here that CA
pining is mentioned as opposed to certificate pinning. In both cases, it
seems to me that pinning these entities makes it very hard for the
application to change CA  or certificate.

-- 
Daniel Migault
Ericsson