Subject: [Last-Call] Artart last call review of draft-ietf-sidrops-rpki-has-no-identity-04

From: Tim Bray via Datatracker <[email-masked]>
Date: Wed, 09 Mar 2022 15:17:56 -0800

Reviewer: Tim Bray
Review result: On the Right Track

I have reviewed draft-ietf-sidrops-rpki-has-no-identity-04.

Preliminary disclosures: I have never previously encountered RPKI and don't
know much about BGP. I do understand PKI issues reasonably well.

Summary: The authors point out that RFC 6480 is at pains to establish that its
certs and keypairs do not assert the identity of any organization, but rather
just the capability of issuing ROAs to support routing. They discuss problems
that could occur should these certs be used in a way that implies they identify
some organization, and go on to say, in section 2, “RPKI-based credentials of
INRs MUST NOT be used to authenticate real-world documents or transactions
without some formal external authentication of the INR and the authority for
the actually anonymous INR holder to authenticate the particular document or
transaction.” Then they repeat this MUST in section 4.

Upon reading this, the following issues occur. None of the questions below are
rhetorical; as mentioned above, my expertise here is very limited.

1. Is this sort of bad-practice use of RPKI keypairs actually occurring? Ie. is
there a threat that needs to be staved off?  I hypothesize that some
Internet-Draft somewhere has suggested this mis-use of RPKIs and the purpose of
draft-ietf-sidrops-rpki-has-no-identity is to give reviewers an extra leg to
stand on when saying "Don't do that".  Which seems reasonable but shouldn't be
necessary? 2. Assuming that people are doing this and we want them to stop, is
issuing this sort of RFC the best way, or even likely to be effective, at doing
so? I grant that it might be effective in suppressing this bad practice in I-Ds
but 6480 seems pretty clear to me. 3. The single MUST assertion being repeated
twice is unnecessary. 4. The MUST assertion feels unnecessarily complicated and
long-winded. I think what they're trying to say is "You MUST NOT perform PKI
operations with these certs except exactly as described, and for the purposes
described, in 6480.” 5. The discussion in section 3 about how the holders of
RPKI keys probably don't issue their own certs but get CAs to do that left me a
bit puzzled.  Is the conclusion that we should admonish CAs not to do this?  Or
is it the case that some key-holders do issue their own certs but are Being
Bad? 6. Section 3 is kind of long and discursive and could likely be shortened
without loss of value. The document might be more useful if there were
subsection 3.1 Issuers of RPKI certificates, 3.2 Organizational issues, etc

It should be obvious that I don't understand whether there's a bad-practice
problem out there, who the bad practitioners are, and whether this document as
an RFC will help stop them.  If it is the case that there is some organization
that is mis-using RFC6480 keys and there is a case to be made that a follow-up
RFC will curtail this practice, then this draft contains the basis of such an
RFC.

[It is also possibly the case that those better acquainted with RPKI will
instantly understand what the problem is and why the language herein will help
deal with it, in which case feel free to ignore most of my comments. ]

---

From: Geoff Huston <[email-masked]>
Date: Wed, 9 Mar 2022 23:50:33 +0000

On 10 Mar 2022, at 10:17 am, Tim Bray via Datatracker <[email-masked]> wrote:
> ...

> deal with it, in which case feel free to ignore most of my comments. ]

These are interesting review comments Tim. I’m not an author of this
draft, but the points you make resonate with me.

The draft appears to be a verbose restatement of Section 2.1 RFC6480. That
original text is short enough to reproduce here: "An important property of
this PKI is that certificates do not attest to the identity of the subject. 
Therefore, the subject names used in certificates are not intended to be
"descriptive".  That is, the resource PKI is intended to provide
authorization, but not authentication.”

(There is also an even shorter exposition in RFC6487 (not references by this
draft) which states in section 4.5: “Subject names are not intended to be 
descriptive of the identity of subject.”

If the point of this draft is “go read RFC6480” then why do we need a meta-RFC
to tell the reader to read another RFC? If the point of the draft is that “people
are doing bad practices with this tech because they have not read the RFCs on
this topic” then I find it difficult to comprehend why publishing yet another RFC
would fix the underlying issue. If they didn't read the primary source RFCs then
why should they read this one? Alternatively, if this draft is making
a novel point that is not adequately covered in existing RFCs then the draft
manages to hide that aspect so well that it is completely lost on me.

So I clearly don't understand what track this draft is supposed to be on, right
wrong. I clearly just don't understand the nature of the problem that publishing
this draft as an RFC would solve.

Geoff

---

From: Michael Richardson <[email-masked]>
Date: Wed, 09 Mar 2022 19:49:04 -0500

> this draft as an RFC would solve.

I had the same question as you and Tim when I read the document.
(My email didn't get through to sidrops... it's not using the global
acceptlist I guess)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Chris Morrow <[email-masked]>
Date: Thu, 10 Mar 2022 03:42:06 +0000

On Thu, 10 Mar 2022 00:49:04 +0000,
Michael Richardson <[email-masked]> wrote:
> 
> [1  <text/plain; utf-8 (quoted-printable)>]
> 

I don't think there is such a list? ('global acceptlist')
(I think I did ack your messages through though (I thought) earlier this week?)

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Mar 2022 20:45:04 -0800

> (I think I did ack your messages through though (I thought) earlier this week?)

See
https://mailarchive.ietf.org/arch/msg/wgchairs/9bHUvKCKqXRT35EC7yE88yQ1WZI/
(The mailarchive finds a few other threads, including a call for chairs to
opt-out of a bulk conversion pass.)

The main guidance seems to be, email [email-masked] if you want
something changed.

-Ben

---

From: Randy Bush <[email-masked]>
Date: Thu, 10 Mar 2022 11:34:28 -0800

hi tim,

thanks for reading and commenting.

> 1. Is this sort of bad-practice use of RPKI keypairs actually
> occurring?

a few years back, two of the co-authors of a lot of sidr rfcs, working
at apnic (supposedly a prudent steward of the net infra), put up a "sign
arbitrary blob" service, with no warnings of the semantics.  one of them
just wrote to say he thought 6480 was sufficient; which pretty much says
it all.

and early drafts and discussions of the first two informative references

   [I-D.ietf-sidrops-rpki-rsc]
              Snijders, J., Harrison, T., and B. Maddison, "Resource
              Public Key Infrastructure (RPKI) object profile for Signed
              Checklist (RSC)", Work in Progress, Internet-Draft, draft-
              ietf-sidrops-rpki-rsc-06, 12 February 2022,
              <https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
              rsc-06.txt>.

   [I-D.ietf-sidrops-rpki-rta]
              Michaelson, G. G., Huston, G., Harrison, T., Bruijnzeels,
              T., and M. Hoffmann, "A profile for Resource Tagged
              Attestations (RTAs)", Work in Progress, Internet-Draft,
              draft-ietf-sidrops-rpki-rta-00, 21 January 2021,
              <https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-
              rta-00.txt>.

brought to light massive misunderstanding and misrepresentation, despite
6480

> this mis-use of RPKIs and the purpose of
> draft-ietf-sidrops-rpki-has-no-identity is to give reviewers an extra
> leg to stand on when saying "Don't do that".

more operators and implementors than ietf reviewers.  this is from an
ops area wg.

> Which seems reasonable but shouldn't be necessary?

sad to say, it seems to be.  

> I grant that it might be effective in suppressing this bad practice in
> I-Ds but 6480 seems pretty clear to me.

tl;dr: ibid

long: tragic to say, but a long line of trucks have been driven through
6480.  this aspect is merely one.  the code and operations providing
rpki infrastructure and its use is not what you want to tell your mom
about.

> 3. The single MUST assertion being repeated twice is unnecessary.
>
> 4. The MUST assertion feels unnecessarily complicated and
> long-winded. I think what they're trying to say is "You MUST NOT
> perform PKI operations with these certs except exactly as described,
> and for the purposes described, in 6480.”

will take those on.

> 5. The discussion in section 3 about how the holders of RPKI keys
> probably don't issue their own certs but get CAs to do that left me a
> bit puzzled.  Is the conclusion that we should admonish CAs not to do
> this?  Or is it the case that some key-holders do issue their own
> certs but are Being Bad?

both.  operationally, there are two paths of issuance.  the RIRs provide
"hosted" service, where their customers have no mechanics and merely use
the RIR's web or api interfaces.  in the "delegated" version of the
service, the RIR issues the base cert for the registrant's resources,
with the SIA pointing to the registrant's repository, and the registrant
CA issues whatever from there.

> 6. Section 3 is kind of long and discursive and could likely be
> shortened without loss of value. The document might be more useful if
> there were subsection 3.1 Issuers of RPKI certificates, 3.2
> Organizational issues, etc
> 
> It should be obvious that I don't understand whether there's a
> bad-practice problem out there

has been tiny, but was threatening to be large.  the discussion of this
draft in the wg has helped ameliorate the fantasies considerably.

> [It is also possibly the case that those better acquainted with RPKI
> will instantly understand what the problem is and why the language
> herein will help deal with it, in which case feel free to ignore most
> of my comments. ]

others will be more eloquent.  steve for example

    https://mailarchive.ietf.org/arch/msg/sidrops/V5OHy_p0po6VmAYFxjK3Wz_2lLI/

or our esteemed AD, to qute him,

> I must admit that I *wanted* to / felt I should be able to use the
> RPKI to do things like sign LOAs and similar "the RIR says I'm the
> 'owner', seem mah cert!" type things, and so, even though the document
> makes me sad, it's useful and needed.

and, as usual, ben is articulate, see

    https://mailarchive.ietf.org/arch/msg/sidrops/93mFbfcBFfngb90MGeR7VaAD28g/

randy