Re: [Sidrops] Artart last call review of draft-ietf-sidrops-rpki-has-no-identity-04

Randy Bush <randy@psg.com> Thu, 10 March 2022 19:34 UTC

Return-Path: <randy@psg.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 199173A1B89; Thu, 10 Mar 2022 11:34:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 OnY1pWmCHpHy; Thu, 10 Mar 2022 11:34:33 -0800 (PST)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 1F5B43A1B83; Thu, 10 Mar 2022 11:34:33 -0800 (PST)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.93) (envelope-from <randy@psg.com>) id 1nSOYP-0004oS-8b; Thu, 10 Mar 2022 19:34:29 +0000
Date: Thu, 10 Mar 2022 11:34:28 -0800
Message-ID: <m2a6dx8uuz.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Tim Bray via Datatracker <noreply@ietf.org>
Cc: art@ietf.org, draft-ietf-sidrops-rpki-has-no-identity.all@ietf.org, last-call@ietf.org, sidrops@ietf.org
In-Reply-To: <164686787641.27464.13731142773840437850@ietfa.amsl.com>
References: <164686787641.27464.13731142773840437850@ietfa.amsl.com>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="ISO-2022-JP"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/PEMsy6Jbef-F5WwENSlWhhRj9b4>
Subject: Re: [Sidrops] Artart last call review of draft-ietf-sidrops-rpki-has-no-identity-04
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: Thu, 10 Mar 2022 19:34:39 -0000

hi tim,

thanks for reading and commenting.

> 1. Is this sort of bad-practice use of RPKI keypairs actually
> occurring?

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

> this mis-use of RPKIs and the purpose of
> draft-ietf-sidrops-rpki-has-no-identity is to give reviewers an extra
> leg to stand on when saying "Don't do that".

more operators and implementors than ietf reviewers.  this is from an
ops area wg.

> Which seems reasonable but shouldn't be necessary?

sad to say, it seems to be.  

> I grant that it might be effective in suppressing this bad practice in
> I-Ds but 6480 seems pretty clear to me.

tl;dr: ibid

long: tragic to say, but a long line of trucks have been driven through
6480.  this aspect is merely one.  the code and operations providing
rpki infrastructure and its use is not what you want to tell your mom
about.

> 3. The single MUST assertion being repeated twice is unnecessary.
>
> 4. The MUST assertion feels unnecessarily complicated and
> long-winded. I think what they're trying to say is "You MUST NOT
> perform PKI operations with these certs except exactly as described,
> and for the purposes described, in 6480.”

will take those on.

> 5. The discussion in section 3 about how the holders of RPKI keys
> probably don't issue their own certs but get CAs to do that left me a
> bit puzzled.  Is the conclusion that we should admonish CAs not to do
> this?  Or is it the case that some key-holders do issue their own
> certs but are Being Bad?

both.  operationally, there are two paths of issuance.  the RIRs provide
"hosted" service, where their customers have no mechanics and merely use
the RIR's web or api interfaces.  in the "delegated" version of the
service, the RIR issues the base cert for the registrant's resources,
with the SIA pointing to the registrant's repository, and the registrant
CA issues whatever from there.

> 6. Section 3 is kind of long and discursive and could likely be
> shortened without loss of value. The document might be more useful if
> there were subsection 3.1 Issuers of RPKI certificates, 3.2
> Organizational issues, etc
> 
> It should be obvious that I don't understand whether there's a
> bad-practice problem out there

has been tiny, but was threatening to be large.  the discussion of this
draft in the wg has helped ameliorate the fantasies considerably.

> [It is also possibly the case that those better acquainted with RPKI
> will instantly understand what the problem is and why the language
> herein will help deal with it, in which case feel free to ignore most
> of my comments. ]

others will be more eloquent.  steve for example

    https://mailarchive.ietf.org/arch/msg/sidrops/V5OHy_p0po6VmAYFxjK3Wz_2lLI/

or our esteemed AD, to qute him,

> I must admit that I *wanted* to / felt I should be able to use the
> RPKI to do things like sign LOAs and similar "the RIR says I'm the
> 'owner', seem mah cert!" type things, and so, even though the document
> makes me sad, it's useful and needed.

and, as usual, ben is articulate, see

    https://mailarchive.ietf.org/arch/msg/sidrops/93mFbfcBFfngb90MGeR7VaAD28g/

randy