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

Randy Bush <randy@psg.com> Tue, 15 March 2022 17:23 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 3FD873A1064; Tue, 15 Mar 2022 10:23:02 -0700 (PDT)
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 sqKng4gRwxp3; Tue, 15 Mar 2022 10:23:00 -0700 (PDT)
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 0AA6F3A0D1C; Tue, 15 Mar 2022 10:23:00 -0700 (PDT)
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 1nUAss-0009nd-0q; Tue, 15 Mar 2022 17:22:58 +0000
Date: Tue, 15 Mar 2022 10:22:57 -0700
Message-ID: <m2h77zku4u.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: Kyle Rose via Datatracker <noreply@ietf.org>
Cc: secdir@ietf.org, draft-ietf-sidrops-rpki-has-no-identity.all@ietf.org, last-call@ietf.org, sidrops@ietf.org
In-Reply-To: <164736391901.8166.304606388310583653@ietfa.amsl.com>
References: <164736391901.8166.304606388310583653@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="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/5j-Aoh3raSKBCdmPjkC7z7homRU>
Subject: Re: [Sidrops] Secdir 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: Tue, 15 Mar 2022 17:23:03 -0000

hi kyle

> Can one of the authors cite a specific reference to the problem that
> this draft is trying to address? A written example of where this
> "false notion" exists?

let be be lazy and quote the response to a similar question in an
artart review

    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

yes, this is depressing and a bit shocking.  sad to say, those terms can
be applied to a fair bit of RPKI deployment.

randy