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
- [Sidrops] Artart telechat review of draft-ietf-si… Tim Bray via Datatracker
- Re: [Sidrops] Artart telechat review of draft-iet… Russ Housley
- Re: [Sidrops] Artart telechat review of draft-iet… Randy Bush
- Re: [Sidrops] [art] Artart telechat review of dra… Francesca Palombini
- Re: [Sidrops] [art] Artart telechat review of dra… Randy Bush
- Re: [Sidrops] [art] Artart telechat review of dra… Russ Housley
- Re: [Sidrops] [art] Artart telechat review of dra… Randy Bush
- Re: [Sidrops] [art] Artart telechat review of dra… Francesca Palombini