The 'I' in RPKI Does Not Stand for Identity
draft-ietf-sidrops-rpki-has-no-identity-07

[Ballot comment]
I also had a similar question as to the intended status, but based on Francesca's comment this issue has already seen plenty of discussion and consideration.

My only other comment is, Walla-Walla Walla-Walla Walla

[Ballot comment]
Thanks for working of this document. It is regretful that we need to have this kind of documentation to clarify or warn people and I hope this works.

I have also struggled with the correct type of this document as some of other AD also did, specially after reading the shepherd's write-up which says "The document is merely text discussing the problem." There has been some discussion on the IESG mailing list and among the ADs, and Francesca confirmed referring to the authors that PS is what discussed and agreed. With that in mind I am casting "no objection" ballot.

[Ballot comment]
Thank you to Kyle Rose for the SECDIR review.

** Section 2
  Given sufficient external, i.e. non-RPKI, verification of authority,
  the use of RPKI-based credentials seems superfluous.

Consider rephrasing this sentence to clarify the application of these credentials.  For example:

Given sufficient external verification of authority (through non-RPKI mechanisms), the use of RPKI-based credentials is superfluous for .

** Section 4.
  Attempts to use RPKI data to authenticate real-world documents or
  other artifacts requiring identity are invalid and misleading.

Recommend describing what is mean by “invalid”.  In the cryptographic operation sense, these signatures are “valid”.  They were just “misleading” in terms of the degree of authenticity they are providing.

[Ballot comment]
The IANA review of this document seems to not have concluded yet.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "invalid"; alternatives might be "not valid", "unenforceable", "not
  binding", "inoperative", "illegitimate", "incorrect", "improper",
  "unacceptable", "inapplicable", "revoked", "rescinded"

Thanks to Matt Joras for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/XxrooGApKU44C2d967vyx73Ydjw).

-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Paragraph 1852, nit:
> als may be userid/password (with two factor authentication one hopes), a har
>                                  ^^^^^^^^^^
When "two-factor" is used as a modifier, it is usually spelled with a hyphen.

Paragraph 1868, nit:
>  client browser certificates, etc. Hence schemes such as [I-D.ietf-sidrops-r
>                                    ^^^^^
A comma may be missing after the conjunctive/linking adverb "Hence".

[Ballot comment]
Thanks for this useful document. 

As others ADs have noted, this document felt like it should be informational rather stds track, although I think that I get why you want to push this through as stds track.

If only we were allowed to use arbitrary CSS in the HTML version of the RFC then you have had the "does not" in the title in bold red flashing text. ;-)

Rob

[Ballot comment]
Thanks for this. The reference to Bill’s Bait & Sushi brought a tear to my eye. I do have a couple comments, hope they help.

1. Section 1 has

                            The RPKI provides authorization to make
  assertions only regarding named IP address blocks, AS numbers, etc.

While the "etc" normally wouldn’t be concerning, in the context of this document I think it is a little bit problematic, because you're trying to be precise about what the RPKI can’t be used for, but “etc” is the opposite of precise, and invites the reader to use their imagination. Maybe replace with “and other INRs”?

2. Section 2 has

  PKI operations MUST NOT be performed with RPKI certificates other
  than exactly as described, and for the purposes described, in
  [RFC6480].  That is, 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.

First, this paragraph is followed by a near–duplicate after the page break, except that one starts with “i.e.“. Probably a cut and paste error or something like that.

Second, The paragraph contradicts itself. The first sentence has a nice clear MUST NOT. But the second sentence provides a “without some” escape hatch. The implication of the second sentence is that if some formal external authorization and authority exists, then the MUST NOT doesn’t apply, rather like a SHOULD NOT/MAY. I realize that in the following paragraph you say that it “seems superfluous” for someone to avail themselves of the implied MAY, but still… which is it? The conflicted nature of this paragraph makes me think you're trying to thread some needle which I can't perceive -- but it sure would be clearer if it stopped after the first sentence, or if the second sentence were cut off after the word "transactions" (so, delete starting from "without"). If you made either of those edits I guess the "seems superfluous" paragraph wouldn't be needed any more either.

My 2 Elbonian cents worth.

[Ballot comment]
Thanks for this. The reference to Bill’s Bait & Sushi brought a tear to my eye. I do have a couple comments, hope they help.

1. Section 1 has

                            The RPKI provides authorization to make
  assertions only regarding named IP address blocks, AS numbers, etc.

While the "etc" normally wouldn’t be concerning, in the context of this document I think it is a little bit problematic, because you're trying to be precise about what the RPKI can’t be used for, but “etc” is the opposite of precise, and invites the reader to use their imagination. Maybe replace with “and other INRs”?

2. Section 2 has

  PKI operations MUST NOT be performed with RPKI certificates other
  than exactly as described, and for the purposes described, in
  [RFC6480].  That is, 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.

First, this paragraph is followed by a near–duplicate after the page break, except that one starts with “i.e.“. Probably a cut and paste error or something like that.

Second, The paragraph contradicts itself. The first sentence has a nice clear MUST NOT. But the second sentence provides a “without some” escape hatch. The implication of the second sentence is that if some formal external authorization and authority exists, then the MUST NOT doesn’t apply, rather like a SHOULD NOT/MAY. I realize that in the following paragraph you say that it “seems superfluous” for someone to avail themselves of the implied MAY, but still… which is it? The conflicted nature of this paragraph makes me think you're trying to thread some needle which I can't perceive -- but it sure would be clearer if it stopped after the first sentence, or if the second sentence were cut off after the word "transactions" (so, delete starting from "without").

My 2 Elbonian cents worth.

[Ballot comment]
Thanks for this. The reference to Bill’s Bait & Sushi brought a tear to my eye. I do have a couple comments, hope they help.

1. Section 1 has

  The RPKI provides authorization to make
  assertions only regarding named IP address blocks, AS numbers, etc.

While the "etc" normally wouldn’t be concerning, in the context of this document I think it is a little bit problematic, because you're trying to be precise about what the RPKI can’t be used for, but “etc” is the opposite of precise, and invites the reader to use their imagination. Maybe replace with “and other INRs”?

2. Section 2 has

  PKI operations MUST NOT be performed with RPKI certificates other
  than exactly as described, and for the purposes described, in
  [RFC6480].  That is, 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.

First, this paragraph is followed by a near–duplicate after the page break, except that one starts with “i.e.“. Probably a cut and paste error or something like that.

Second, The paragraph contradicts itself. The first sentence has a nice clear MUST NOT. But the second sentence provides a “without some” escape hatch. The implication of the second sentence is that if some formal external authorization and authority exists, then the MUST NOT doesn’t apply, rather like a SHOULD NOT/MAY. I realize that in the following paragraph you say that it “seems superfluous” for someone to avail themselves of the implied MAY, but still… which is it? The conflicted nature of this paragraph makes me think you're trying to thread some needle which I can't perceive -- but it sure would be clearer if it stopped after the first sentence, or if the second sentence were cut off after the word "transactions" (so, delete starting from "without").

My 2 Elbonian cents worth.

[Ballot comment]
Thank you for the work done in this much needed document.

Thanks to Chris Morrow for the shepherd's write-up even if a justification for the intended status would have been welcome (esp on this one).

Please find below some minor comments:

Abstract: you may want to rephrase "This document attempts to put that notion to rest." as it is not really clear to non-English speakers.

Section 1: suggest to introduce the acronym "BB&S" at first use.

Section 2: should the claim "as X.400 learned" be explained or a reference be added ?

Hope this helps

-éric

[Ballot comment]
Thank you for the work on this document.

Many thanks to Tim Bray for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/SKUKjoE9bPh62XsVezoD5mPAkz4/, and to the authors for addressing Tim's comments.

For the record, I did have a question about proper track for this document, but the authors have confirmed that "Standard track" was discussed and agreed within the WG, although the document might have felt more like Informational to me.

Francesca

[Ballot discuss]
Thank you for the work on this document.

Many thanks to Tim Bray for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/SKUKjoE9bPh62XsVezoD5mPAkz4/, and to the authors for addressing Tim's comments.

I have one question for consideration (which will not require any textual changes to the document): is "Standard Track" the proper track of RFC for this document?

I am happy to be told by the authors, working group or responsible AD that yes - this has been discussed and the consensus was that "Standard Track" is the most appropriate track for this document. Normally I would look for such information in the shepherd write-up, but unfortunately I can't find my answer there, nor through my superficial archive search.

Note I am not questioning the need for this document, which I understand has been discussed and has consensus, barely its track - doesn't this fit better as Informational, or even BCP (although I concur with Murray, BCP does not seem appropriate)?

Francesca

[Ballot comment]
BCP doesn't seem appropriate, but I wish there was a stronger document status we could give this.

In Section 2:

  If it tried to do so, aside from the liability, it would end in a
  world of complexity with no proof of termination, as X.400 learned.

Is there a reference describing the X.400 lesson that could be included here?

  Registries such as the Regional Internet Registries (RIRs) provide
  INR to real-world identity mapping through whois and similar
  services.  They claim to be authoritative, at least for the INRs
  which they allocate.

I think "WHOIS" is properly (or at least traditionally) in all-caps.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-sidrops-rpki-has-no-identity-04, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-03-18):

From: The IESG
To: IETF-Announce
CC: draft-ietf-sidrops-rpki-has-no-identity@ietf.org, morrowc@ops-netman.net, sidrops-chairs@ietf.org, sidrops@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (The I in RPKI does not stand for Identity) to Proposed Standard


The IESG has received a request from the SIDR Operations WG (sidrops) to
consider the following document: - 'The I in RPKI does not stand for Identity'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-03-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  There is a false notion that Internet Number Resources (INRs) in the
  RPKI can be associated with the real-world identity of the 'owner' of
  an INR.  This document attempts to put that notion to rest.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-has-no-identity/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

PROPOSED STANDARD


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  There is a false notion that Internet Number Resources (INRs) in the
  RPKI can be associated with the real world identity of the 'owner' of
  an INR.  This document attempts to put that notion to rest.

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The WG consensus was strong enough, without any real dissenting discussion.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document is merely text discussing the problem. With that in mind, it's totally fine.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd: Chris Morrow (morrowc@ops-netman.net)
Resp AD:  Warren Kumari (warren@kumari.net)


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was reviewed multiple times by the shepherd and the working group through 4 revisions.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

no concerns

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

no special review required.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.


no concerns/issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, no IPR claims are made.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

no IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

solid enough.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

no threats of appeal or otherwise upset people.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


There's 1 error noted in the NITS review:
  ** Downref: Normative reference to an Informational RFC: RFC 6480

this will be corrected before publication.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

no formal review is required.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

no

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

** Downref: Normative reference to an Informational RFC: RFC 6480

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


it will not.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The shepherd has reviewed the IANA section, there are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.


None required.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?


no yang here.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

PROPOSED STANDARD


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
  There is a false notion that Internet Number Resources (INRs) in the
  RPKI can be associated with the real world identity of the 'owner' of
  an INR.  This document attempts to put that notion to rest.

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

The WG consensus was strong enough, without any real dissenting discussion.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document is merely text discussing the problem. With that in mind, it's totally fine.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Shepherd: Chris Morrow (morrowc@ops-netman.net)
Resp AD:  Warren Kumari (warren@kumari.net)


(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document was reviewed multiple times by the shepherd and the working group through 4 revisions.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

no concerns

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

no special review required.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.


no concerns/issues.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes, no IPR claims are made.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

no IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

solid enough.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

no threats of appeal or otherwise upset people.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.


There's 1 error noted in the NITS review:
  ** Downref: Normative reference to an Informational RFC: RFC 6480

this will be corrected before publication.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

no formal review is required.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

no

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

** Downref: Normative reference to an Informational RFC: RFC 6480

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.


it will not.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The shepherd has reviewed the IANA section, there are no IANA considerations.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

N/A

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.


None required.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?


no yang here.