Re: [Sidrops] John Scudder's No Objection on draft-ietf-sidrops-rpki-has-no-identity-06: (with COMMENT)

Job Snijders <job@fastly.com> Tue, 19 April 2022 09:29 UTC

Return-Path: <job@fastly.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 983083A0E41 for <sidrops@ietfa.amsl.com>; Tue, 19 Apr 2022 02:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=fastly.com
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 MMgeJJp1jwFr for <sidrops@ietfa.amsl.com>; Tue, 19 Apr 2022 02:29:03 -0700 (PDT)
Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 848BE3A0E42 for <sidrops@ietf.org>; Tue, 19 Apr 2022 02:29:03 -0700 (PDT)
Received: by mail-ed1-x52e.google.com with SMTP id 11so15436652edw.0 for <sidrops@ietf.org>; Tue, 19 Apr 2022 02:29:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastly.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=h0uxoQFULsFaRr0APSN/0wAo7qR9XiR2y8r0723t4z4=; b=KarJXLwqXEUN8QERYuyk08oO5dnilhO4cDJWbZUfYUZibrTpwybIgVzA1nN5Ynkk8E qwBBTpOBphdvnrp/6cGmN4l0fth3WkiaQzXxHw9Jy8Ps8NIDK9b1D1hK3uCCacHmA5u8 zXEBCO+oiOaZor1pUtnKBiPJOXFr1QMUYOcCI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to; bh=h0uxoQFULsFaRr0APSN/0wAo7qR9XiR2y8r0723t4z4=; b=VJHPD1xwr0fgtKn4S8iXN4mKpaZxZ8hHZ2dYKzFunsNaCRCiLnd/0PznZJ+aeNpSWl r4mWHf6eR9BR0MN4mYbOcKAfieY9neKuWSbjTrIUpljRfh0qu0qkrAWqiXtDSwndAgnL AtLzY4rmxTIuhRmFLBy5MkiimRjjnEYLha89y2ztUWQPEBz73Qj84CB6RlygdlNQBABx a+EHoMM8mI6O3yawaXLps6t16O0QQsRNcyV8bUTlRBN2EC79JuUEMboFW3JVyx5Vhgj3 GkO2YSEtGAt/2tEl2Hv6RAHcP1DSOsoqt3pVXxXbfdQ81lQvBA4K+jtjwA7ClIQDYso6 Oqyw==
X-Gm-Message-State: AOAM530woc9QLjI8ZpJk2mRMQ2ylUD0zRnHeJ3SirTOz0FwbBsiss+HE 8f8TnCdly8AGb4D8YSAPwdM7kA==
X-Google-Smtp-Source: ABdhPJysqpn73fTdR4mhG28kPuUcWmxGXrLEOzyo0yl6uKs+VqJ76ky6YrVTd/edldxUCLT0/rCE+A==
X-Received: by 2002:a05:6402:1148:b0:416:a4fb:3c2e with SMTP id g8-20020a056402114800b00416a4fb3c2emr16411084edw.182.1650360541576; Tue, 19 Apr 2022 02:29:01 -0700 (PDT)
Received: from snel ([2a10:3781:276:2:16f6:d8ff:fe47:2eb7]) by smtp.gmail.com with ESMTPSA id p22-20020aa7c4d6000000b004209e0deb3esm8224495edr.30.2022.04.19.02.29.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Apr 2022 02:29:01 -0700 (PDT)
Date: Tue, 19 Apr 2022 11:28:59 +0200
From: Job Snijders <job@fastly.com>
To: Randy Bush <randy@psg.com>
Cc: John Scudder via Datatracker <noreply@ietf.org>, sidrops-chairs@ietf.org, morrowc@ops-netman.net, sidrops@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-sidrops-rpki-has-no-identity@ietf.org
Message-ID: <Yl6A2xcLUnqPvrNz@snel>
References: <165032923578.31390.12269095928327271267@ietfa.amsl.com> <m235i9ras0.wl-randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <m235i9ras0.wl-randy@psg.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/POjzUvv4x_DcYw71t6CBFu7sUg4>
Subject: Re: [Sidrops] John Scudder's No Objection on draft-ietf-sidrops-rpki-has-no-identity-06: (with COMMENT)
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, 19 Apr 2022 09:29:09 -0000

Hi all,

On Mon, Apr 18, 2022 at 08:51:11PM -0700, Randy Bush wrote:
> >    The RPKI provides authorization to make assertions only regarding
> >    named IP address blocks, AS numbers, etc.
> > 
> > While the "etc" normally wouldn’t be concerning, in the context of
> > this document I think it is a little bit problematic, because you're
> > trying to be precise about what the RPKI can’t be used for, but “etc”
> > is the opposite of precise, and invites the reader to use their
> > imagination. Maybe replace with “and other INRs”?
> 
> i tried, but then there is ASPA.  and is it the nose of a camel carrying
> all sorts of non INR info?  [ yes, an ASPA contains AS numbers.  but it
> is really about their relationships. ]
> 
>     regarding Internet Number Resources (INRs), such as IP prefixes, AS
>     numbers, and data such as ASPA records.
> 
> > 2. Section 2 has
> > 
> >    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.
> > 
> > First, this paragraph is followed by a near–duplicate after the page
> > break, except that one starts with “i.e.“. Probably a cut and paste
> > error or something like that.
> 
> sigh.  sorry.  and thanks.
> 
> > Second, The paragraph contradicts itself. The first sentence has a
> > nice clear MUST NOT. But the second sentence provides a “without some”
> > escape hatch. The implication of the second sentence is that if some
> > formal external authorization and authority exists, then the MUST NOT
> > doesn’t apply, rather like a SHOULD NOT/MAY. I realize that in the
> > following paragraph you say that it “seems superfluous” for someone to
> > avail themselves of the implied MAY, but still… which is it? The
> > conflicted nature of this paragraph makes me think you're trying to
> > thread some needle which I can't perceive -- but it sure would be
> > clearer if it stopped after the first sentence, or if the second
> > sentence were cut off after the word "transactions" (so, delete
> > starting from "without"). If you made either of those edits I guess
> > the "seems superfluous" paragraph wouldn't be needed any more either.
> 
>     That is, RPKI-based credentials of INRs MUST NOT be used to
>     authenticate real-world documents or transactions.  That might be
>     done with some formal external authentication of authority for an
>     otherwise anonymous INR holder to authenticate the particular
>     document or transaction.  Given such external, i.e. non-RPKI,
>     verification of authority, the use of RPKI-based credentials seems
>     superfluous.

That seems a pretty significant departure from the original text! I
object to deletion of the 'without' part of the sentence.

Randy, is this 'no-identity' document intended to obstruct publication
of https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc ?

Kind regards,

Job