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

[Richard Barnes <[e-mail]>]

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

On Tue, Jul 28, 2020 at 6:03 PM Eric Rescorla <[e-mail]> wrote:

> 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
>>
> _______________________________________________
> saag mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/saag
>