IETF Logo Mail Archive

Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.txt

Tim Bruijnzeels <tim@nlnetlabs.nl> Mon, 07 September 2020 12:42 UTC

Return-Path: <tim@nlnetlabs.nl>
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 8E87D3A0CA2 for <sidrops@ietfa.amsl.com>; Mon, 7 Sep 2020 05:42:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nlnetlabs.nl
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 SBLs1CM_ssIH for <sidrops@ietfa.amsl.com>; Mon, 7 Sep 2020 05:42:54 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (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 479D43A0CA1 for <sidrops@ietf.org>; Mon, 7 Sep 2020 05:42:54 -0700 (PDT)
Received: from yoda.fritz.box (unknown [IPv6:2001:981:4b52:1:fce7:462d:d025:2a3d]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 768DF26399; Mon, 7 Sep 2020 14:42:51 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=fail (p=none dis=none) header.from=nlnetlabs.nl
Authentication-Results: dicht.nlnetlabs.nl; spf=fail smtp.mailfrom=tim@nlnetlabs.nl
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1599482571; bh=NXY3GdtHi2333PlFM6U5CiJbMzEuwDEWfRPl5C9Oxtc=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=jf8tYePVjYLmxfz08KDzVAa6tRqOZy6tYeggT/Uz2Kxn1kGYvEYjnOpfXa/8rfY4O MdlSIdPq0kUdGItOl6jD/j/eLXe6m0cq79fTOSuQMPArYvAHIUziJrZW0pTpbUmRZ0 C90QucUsfcKj3bjs/84JUMXtOu6i6HGQ1iQScLuE=
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <C011189B-AFEB-41BD-96F9-20AA78699ED2@vigilsec.com>
Date: Mon, 07 Sep 2020 14:42:51 +0200
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <A540AC86-A0FD-483E-B754-AA52C2A82688@nlnetlabs.nl>
References: <159890072559.31155.191532586512778700@ietfa.amsl.com> <150E4A91-2EC6-4B88-8AD9-E7C88CC64D31@nlnetlabs.nl> <2B4CE028-03E9-4B06-AEFD-D6D2958D91B8@vigilsec.com> <47B41A31-D557-46E1-9EE7-56352C604224@nlnetlabs.nl> <C011189B-AFEB-41BD-96F9-20AA78699ED2@vigilsec.com>
To: Russ Housley <housley@vigilsec.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/UIkrgH8x5Lftq2V0cQJOSn4own8>
Subject: Re: [Sidrops] I-D Action: draft-ietf-sidrops-deprecate-rsync-00.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: Mon, 07 Sep 2020 12:42:56 -0000

Hi,

> On 4 Sep 2020, at 22:34, Russ Housley <housley@vigilsec.com> wrote:
> 
> Tim:
> 
>>> I think that RFC 6487 should also be updated to adjust the RPKI certificate profile.
>> 
>> Can you please elaborate why?
>> 
>> My personal drive with this draft, despite its name perhaps, is to deprecate the *operational* dependency on rsync. In my opinion the rsync URIs can stay and serve as namespaces, even if the servers are not guaranteed to be available. Think XML name spaces. I don't think we need to forbid running rsyncd either.
> 
> For example, RFC 6487, Section 4.8.6 says:
> 
>   ... The preferred URI access mechanism is a single rsync
>   URI ("rsync://") [RFC5781] that references a single inclusive CRL for
>   each issuer.
> 
>   ... Other access form URIs MAY be used in addition to the
>   rsync URI, representing alternate access mechanisms for this CRL.
> 
> There are similar words in Sections 4.8.7, 4.8.8.1, and 4.8.8.2.
> 
> It seem to me you are changing the "preferred" way to handle these, even if both are allowed for decades.

Right, thank you for this pointer!

I think I have misremembered some of what RFC 6487 said. It seems that even though only 'rsync' is used to today for the CRL DP, SIA and AIA - other access mechanisms are explicitly allowed.

I would not feel safe about including https in there today without some proper field testing, but it seems that updating this may indeed be less problematic than I thought. It would still leave questions around certificate provisioning (6492) and publication (8181). I need to think about this a bit.

Tim



> 
>> 
>>> In phase 1, several URLs in the certificate could offer rsync:// and rrdp://, and then in Phase 4 (not documented), the rsync:// can get dropped.
>> 
>> It may not be aesthetically pleasing, but removing the rsync URIs completely is a much, much bigger effort. Incomplete dump of pointers of what would be affected
> 
> I agree, and that it is why I called it Phase 4, which is beyond the scope of this document.
> 
> Russ

v2.23.0 | Report a Bug | By Email