Subject: [Uta] Pinning

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Sep 2021 15:52:23 +0000

I would like to remove the discussion of pinning from 5126bis for the following reason:

  *   It’s an escape hatch, saying “do all these things but if you don’t get a match, you can pin.”
  *   The current wording allows its use, anyway.
  *   Pinning is bad.

A proposed change is in https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/19

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Sep 2021 12:32:55 -0400

> I would like to remove the discussion of pinning from 5126bis for the following reason:

[ You surely meant 6125, but let your fingers do the talking... ]

>   *   The current wording allows its use, anyway.

I disagree with this change, because my read of the spec is that this it
does not describe the "bad" form of pinning that *requires* a previously
observed certificate or public key (e.g. HPKP) to continue to be the one
presented by the server.

Rather, this form of "pinning" is a user-initiated override that allows
a mismatched certificate to be *additionally* acceptable for the service
the user is trying to reach.

For example, MacOS Keychain variously allows users to configure specific
certificates to be trusted for particular peers.

While this is perhaps dangerous in the hands of clueless users, it is
also useful when used correctly.

Perhaps the text can be made more concise, but I don't think full
removal is warranted.  This is *not* the fragile key pinning from HPKP.

-- 
    Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Sep 2021 16:45:24 +0000

Right now the text has this.  Is more needed?

### Failure: No Match Found

If the client does not find a presented identifier matching any of the
reference identifiers then the client MUST
proceed as described as follows.

If the client is an automated application not directly controlled
by a human user, then it SHOULD terminate the communication attempt with
a bad certificate error and log the error appropriately.
An automated application
MAY provide a configuration setting that disables this behavior, but it
MUST enable the behavior by default.

If the client is an interactive client that is directly controlled by a human
user, then it SHOULD inform the user of the identity mismatch and automatically
terminate the communication attempt with a bad certificate error; this behavior
is preferable because it prevents users from inadvertently bypassing security
protections in hostile situations.

Some interactive clients give advanced users the option
of proceeding with acceptance despite the identity mismatch.
Although this behavior can be appropriate in certain specialized
circumstances, it needs to be handled with
extreme caution, for example by first encouraging even an advanced user to
terminate the communication attempt and, if the advanced user chooses to
proceed anyway, by forcing the user to view the entire certification path
before proceeding.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 8 Sep 2021 12:59:14 -0400

> proceed anyway, by forcing the user to view the entire certification path

This is most of what's needed.  Plus something along the lines of:

    In some cases the user should be able to accept the certificate in
    question as valid also for subsequent connections.  Such ad-hoc
    "pinning" should typically not restrict future connections to just
    the pinned certificate.

    Local policy that statically enforces a given certificate for a
    given peer is best made available only as prior configuration,
    rather than a just-in-time override for a failed connection.

Feel free to word smith if largely acceptable, or clarify objections if
not...

-- 
    Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 8 Sep 2021 17:12:51 +0000

Largely acceptable to me :)  I'll tweak a bit and add it to the pull request soon.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Sep 2021 13:55:44 +0000

>    This is most of what's needed.  Plus something along the lines of:

I updated https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/19 to have something based on Viktor's suggestion. The main wording changes were about using MUST MAY SHOULD language in that whole section.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Sep 2021 11:12:02 -0400

On Thu, Sep 09, 2021 at 01:55:44PM +0000, Salz, Rich wrote:

> I updated
> https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/19 to have
> something based on Viktor's suggestion. The main wording changes were
> about using MUST MAY SHOULD language in that whole section.

Works for me, I'd be good to hear comments from others, assuming anyone
else is following this...

-- 
    Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 9 Sep 2021 16:16:12 +0100

> else is following this...

The new text looks reasonable to me.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 9 Sep 2021 09:31:53 -0600

> The new text looks reasonable to me.

I have no strong objections (especially because this simplifies things
for readers and implementers).

While we're at it, we might move any text about pinning to an appendix.

Peter