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

Russ Housley <housley@vigilsec.com> Fri, 08 April 2022 20:14 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1053A1156; Fri, 8 Apr 2022 13:14:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HemU927ihD9n; Fri, 8 Apr 2022 13:14:21 -0700 (PDT)
Received: from mail3.g24.pair.com (mail3.g24.pair.com [66.39.134.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6BBE3A1159; Fri, 8 Apr 2022 13:14:21 -0700 (PDT)
Received: from mail3.g24.pair.com (localhost [127.0.0.1]) by mail3.g24.pair.com (Postfix) with ESMTP id A047B129A08; Fri, 8 Apr 2022 16:14:20 -0400 (EDT)
Received: from [10.0.1.2] (pfs.iad.rg.net [198.180.150.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail3.g24.pair.com (Postfix) with ESMTPSA id 839661297B9; Fri, 8 Apr 2022 16:14:20 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <164936575713.6320.18195760378286197162@ietfa.amsl.com>
Date: Fri, 08 Apr 2022 16:14:20 -0400
Cc: art@ietf.org, draft-ietf-sidrops-rpki-has-no-identity.all@ietf.org, Last Call <last-call@ietf.org>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <10652A23-5534-423B-B8AC-3320881CA38A@vigilsec.com>
References: <164936575713.6320.18195760378286197162@ietfa.amsl.com>
To: Tim Bray <tbray@textuality.com>
X-Mailer: Apple Mail (2.3445.104.21)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/X-ctMk332LCU__dhgBBkyQwQbkQ>
Subject: Re: [Sidrops] Artart telechat review of draft-ietf-sidrops-rpki-has-no-identity-05
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Apr 2022 20:14:26 -0000

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 <noreply@ietf.org> wrote:
> 
> 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.

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.

> 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?

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

	The RPKI is for Authorization

> - 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?  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.

> - 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.)

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.

> 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.

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