Subject: [Sidrops] Artart telechat review of draft-ietf-sidrops-rpki-has-no-identity-05

From: Tim Bray via Datatracker <[email-masked]>
Date: Thu, 07 Apr 2022 14:09:17 -0700

Reviewer: Tim Bray
Review result: Ready with Issues

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

It seems obvious that the WG needs to develop consensus whether or not a
document such as this, which essentially says "REALLY don't do what this other
RFC says not to", is a useful and appropriate tool. If no such consensus exists
we can stop reviewing revisions and save time.

If we assume that the document is useful and appropriate…

- In section 2, the title "The Bottom Line" doesn’t seem appropriate.  Could
this be expressed a little less figuratively?

- In section 2, the phrase "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." leaves me blank. If we assume that this is likely to make sense to
others likely to read this, disregard this.

- In section 2, the two MUST assertions in successive paragraphs are a little
puzzling. Is the second a proper subset of the first (looks like it to me)?  If
so, does it need to exist? Maybe it's trying to be an example, in which case it
should say "e.g." instead of "i.e."  If it's really an "i.e.", i.e. a
restatement of the first MUST, then why does the first MUST need to exist? 
Also, I found the second MUST hard to understand (reminder: not an expert in
this domain, feel free to disregard.)

And, since this is the second time I've been asked, I do have a philosophical
unease about this document.  Whenever there is a key-pair, there is an identity
in play: The entity which can arrange for documents to be signed with the
private key. Which in this particular case, means the entity which has at some
point in time could generate ROAs.  This draft implies that there could never
in any conceivable world be a useful result of having confidence that some
document was signed by whoever it is that at that point in time could generate
ROAs for some INR out there. Not the “owner”, not the “controller”, just
whoever it is does the ROAs. How can you know that that could never be useful? 
In general, when a protocol element or online resource can be used to do
something, and someone comes around saying “but you shouldn’t want to do that
thing”, I get nervous.

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Apr 2022 16:14:20 -0400

Tim:

Thanks for taking the time to read the document and submit a review.

> On Apr 7, 2022, at 5:09 PM, Tim Bray via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Tim Bray

Yes.  In fact, this seems to need repeated and highlighted.  This was written when a system was deployed.  initially, I considered it a reminder, but the SIDROPS WG felt that it was important enough to publish.

> this be expressed a little less figuratively?

I am not really sure what section title works better.  How about:

	The RPKI is for Authorization

> others likely to read this, disregard this.

How about we drop the end of the sentence?  With some editing, I suggest:

   That the RPKI does not authenticate real-world identity is by design.
   If it tried to do so, aside from the additional liability, it would also add
   considerable complexity.

> this domain, feel free to disregard.)

I suggest that we merge the two paragraphs:

   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.

Hopefully this make it clear that he second MUST NOT is talking about an example of the first one.

> something, and someone comes around saying “but you shouldn’t want to do that

It is an authorization, not an identity.  RFC 6484 says:

   The most important and distinguishing aspect of the PKI for which
   this policy was created is that it does not purport to identify an
   INR holder via the subject name contained in the certificate issued
   to that entity.  Rather, each certificate issued under this policy is
   intended to enable an entity to assert, in a verifiable fashion, that
   it is the current holder of an INR based on the current records of
   the entity responsible for the resources in question.  Verification
   of the assertion is based on two criteria: the ability of the entity
   to digitally sign data that is verifiable using the public key
   contained in the corresponding certificate, and validation of that
   certificate in the context of this PKI.

Russ

---

From: Randy Bush <[email-masked]>
Date: Fri, 08 Apr 2022 15:09:23 -0700

tim and russ:

>> It seems obvious that the WG needs to develop consensus whether or
>> not a document such as this, which essentially says "REALLY don't do
>> what this other RFC says not to", is a useful and appropriate
>> tool. If no such consensus exists we can stop reviewing revisions and
>> save time.

as it passed wglc and is in ietf last call, is it not safe to presume
this is the case?  i confuse easily.  what am i missing here?

the last time chasing this woozle around the tree, i thought we made
pretty clear that, sad to say, history has shown it is indeed needed.

>> - In section 2, the title "The Bottom Line" doesn’t seem appropriate.
>> Could this be expressed a little less figuratively?
> 

how about "To Summarize?"

>> - In section 2, the phrase "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." leaves me blank. If we assume that
>>   this is likely to make sense to others likely to read this,
>>   disregard this.
> 
> How about we drop the end of the sentence?

the X.400 ref was dropped the other day per murray kucherawy's review.

>> - In section 2, the two MUST assertions in successive paragraphs are
>>   a little puzzling. Is the second a proper subset of the first
>>   (looks like it to me)?  If so, does it need to exist? Maybe it's
>>   trying to be an example, in which case it should say "e.g." instead
>>   of "i.e."  If it's really an "i.e.", i.e. a restatement of the
>>   first MUST, then why does the first MUST need to exist?  Also, I
>>   found the second MUST hard to understand (reminder: not an expert
>>   in this domain, feel free to disregard.)
> 

to quote a grandchild, whatever.

unless an AD requests otherwise, let's hold publishing a revision for a
while.

randy

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 12 Apr 2022 13:39:39 +0000

Tim: many thanks for this review. Randy, Russ: thanks for taking Tim’s comments into account. Very minor – I personally would vote for “The RPKI is for Authorization” to “To Summarize”, since that gives a better hint of the section content.

I balloted DISCUSS on the document because I have a question about the chosen track for the document, but I expect to remove the block after a short discussion about it.

Francesca

From: art <[email-masked]> on behalf of Randy Bush <[email-masked]>
Date: Saturday, 9 April 2022 at 00:10
To: Russ Housley <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Tim Bray <[email-masked]>, Last Call <[email-masked]>
Subject: Re: [art] Artart telechat review of draft-ietf-sidrops-rpki-has-no-identity-05

>> - In section 2, the title "The Bottom Line" doesn¢t seem appropriate.

randy

_______________________________________________
art mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/art

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Apr 2022 11:43:48 -0700

> Tim: many thanks for this review. Randy, Russ: thanks for taking Tim’s
> comments into account. Very minor – I personally would vote for “The
> RPKI is for Authorization” to “To Summarize”, since that gives a
> better hint of the section content.

wfm if it works for russ, wg chairs, and ace

> I balloted DISCUSS on the document because I have a question about the
> chosen track for the document, but I expect to remove the block after
> a short discussion about it.

it was at first.  but the wg decided otherwise, pretty much because of
the really disgusting abuses.

randy

---

From: Russ Housley <[email-masked]>
Date: Tue, 12 Apr 2022 15:13:23 -0400

> On Apr 12, 2022, at 2:43 PM, Randy Bush <[email-masked]> wrote:
> 

Fine with me.

> the really disgusting abuses.

Right.  WG choose to progress as a standards-track document.

Russ

---

From: Randy Bush <[email-masked]>
Date: Tue, 12 Apr 2022 13:19:12 -0700

>> wfm if it works for russ, wg chairs, and ace

if and when i get electrical power back

randy

---

From: Francesca Palombini <[email-masked]>
Date: Tue, 12 Apr 2022 20:22:03 +0000

Hi Russ, Randy,

Thanks for confirming that this has been discussed and agreed on – I will remove the DISCUSS.

Francesca

From: Russ Housley <[email-masked]>
Date: Tuesday, 12 April 2022 at 21:13
To: Randy Bush <[email-masked]>, Francesca Palombini <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Tim Bray <[email-masked]>
Subject: Re: [art] Artart telechat review of draft-ietf-sidrops-rpki-has-no-identity-05

Fine with me.

Russ