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

From: Kyle Rose via Datatracker <[email-masked]>
Date: Tue, 15 Mar 2022 10:05:19 -0700

Reviewer: Kyle Rose
Review result: Ready

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area directors.
 Document editors and WG chairs should treat these comments just like any other
last call comments.

This document is Almost Ready, but its publication as an RFC may or may not be
the right way to address the problem it is targeted at.

Can one of the authors cite a specific reference to the problem that this draft
is trying to address? A written example of where this "false notion" exists?

If the sole purpose of this document is to state a normative prohibition on one
aspect of RPKI as described in the informational RFC 6480, would a better
approach not be to normatively specify RPKI via a 6480bis on standards track?
It feels weird to create a single normative prohibition for a specification
that is otherwise classified as informational, but perhaps there is sufficient
precedent for this.

My one nit suggestion would be to make some of the language a little less
casual, starting with the abstract.

---

From: Randy Bush <[email-masked]>
Date: Tue, 15 Mar 2022 10:22:57 -0700

hi kyle

> Can one of the authors cite a specific reference to the problem that
> this draft is trying to address? A written example of where this
> "false notion" exists?

let be be lazy and quote the response to a similar question in an
artart review

    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

yes, this is depressing and a bit shocking.  sad to say, those terms can
be applied to a fair bit of RPKI deployment.

randy

---

From: Kyle Rose <[email-masked]>
Date: Wed, 16 Mar 2022 16:01:33 -0400

> let be be lazy and quote the response to a similar question in an

Heh... serves me right. I did read the artart review, but not any follow-ups.

> ...

Ok, so I appreciate the problem. I'm still not sure this is quite the
right way to address it. This feels a bit too "protocol police"-ish to
me. Publishing a new RFC to reiterate something that is already
covered by an earlier spec in the hopes that it will deter willfulness
seems like trying to fix something by repeatedly banging on it. Do we
need a "No, we *really* mean it" track in the series? It seems like
vigilance around implementations will be required either way. ISTM
that the best way to address this particular problem is to make sure
the folks in industries that develop RPKI implementations understand
this, which probably means contacting them directly and pointing them
at the existing text that already makes clear that this is a bad idea,
whether in 6480 or in a mailing list archive someplace.

To be clear, I don't feel *especially* strongly about this; I'm mostly
just expressing skepticism of the degree of value in this approach.

Kyle