IETF Logo Mail Archive

Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt

Di Ma <madi@rpstir.net> Tue, 15 June 2021 02:35 UTC

Return-Path: <madi@rpstir.net>
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 947EF3A1ABA for <sidrops@ietfa.amsl.com>; Mon, 14 Jun 2021 19:35:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable 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 KZEqvxqLliXQ for <sidrops@ietfa.amsl.com>; Mon, 14 Jun 2021 19:35:37 -0700 (PDT)
Received: from out20-74.mail.aliyun.com (out20-74.mail.aliyun.com [115.124.20.74]) (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 299D83A1AB9 for <sidrops@ietf.org>; Mon, 14 Jun 2021 19:35:36 -0700 (PDT)
X-Alimail-AntiSpam: AC=CONTINUE; BC=0.2254573|-1; CH=green; DM=|CONTINUE|false|; DS=CONTINUE|ham_regular_dialog|0.0375278-0.00105513-0.961417; FP=0|0|0|0|0|-1|-1|-1; HT=ay29a033018047194; MF=madi@rpstir.net; NM=1; PH=DS; RN=3; RT=3; SR=0; TI=SMTPD_---.KSLdn0F_1623724530;
Received: from smtpclient.apple(mailfrom:madi@rpstir.net fp:SMTPD_---.KSLdn0F_1623724530) by smtp.aliyun-inc.com(10.147.41.121); Tue, 15 Jun 2021 10:35:31 +0800
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Di Ma <madi@rpstir.net>
In-Reply-To: <914036da-a5d0-060b-b5f3-2693d204c1e2@verizon.net>
Date: Tue, 15 Jun 2021 10:35:29 +0800
Cc: Tim Bruijnzeels <tim@nlnetlabs.nl>, sidrops@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B64F812B-0BC8-4072-86AF-DDDD0428DF5D@rpstir.net>
References: <4576a83c-4118-9e4e-aec1-e8e9b0a1a069.ref@verizon.net> <4576a83c-4118-9e4e-aec1-e8e9b0a1a069@verizon.net> <1EF06618-5BF8-46CE-A25C-37D98867EADF@nlnetlabs.nl> <9dcd34e6-3b07-c8fc-99b3-df9365cb19f1@verizon.net> <44CDF8B7-B099-499F-94A5-914238FAFA51@nlnetlabs.nl> <914036da-a5d0-060b-b5f3-2693d204c1e2@verizon.net>
To: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/iCJVnLUI_ooGyOPIkcLwslWSMvE>
Subject: Re: [Sidrops] draft-ietf-sidrops-6486bis-04.txt
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 Jun 2021 02:35:40 -0000

Steve,

> 
> I propose the following text to begin Section 6:
> 
>   Each RP MUST use the current manifest of a CA to control addition of listed
>   files to the set of signed objects the RP employs for validating basic RPKI
>   objects: certificates, ROAs, and CRLs. Any files not
>   listed on the manifest MUST NOT be used for validation of these objects.
>   However, files not listed on a manifest MAY be employed to validate other
>   signed objects, if the profile of the object type explicitly states that
>   such behavior is allowed. Note that relying on files not listed in a
>   manifest may allow an attacker to effect substitution attacks against such
>   objects.
> Steve
> 

Does your proposal mean we have to extend RFC 3779 or RFC 6487 to generally support an RPKI object noting itself required in MFT?

Or we just need to make RSC/RTA to offer such information?

I think the former will bring more tasks for IETF but may be a good way to enhance the security of the RPKI.

Di

v2.23.0 | Report a Bug | By Email