Re: [Sidrops] nlnet rp and rsync

Russ Housley <housley@vigilsec.com> Mon, 11 May 2020 14:44 UTC

Return-Path: <housley@vigilsec.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 8A9883A09AE for <sidrops@ietfa.amsl.com>; Mon, 11 May 2020 07:44:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 kePRsHne3ll1 for <sidrops@ietfa.amsl.com>; Mon, 11 May 2020 07:44:05 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7B73A0B8E for <sidrops@ietf.org>; Mon, 11 May 2020 07:44:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 5FC10300B3F for <sidrops@ietf.org>; Mon, 11 May 2020 10:44:02 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qn3_kzROwDFV for <sidrops@ietf.org>; Mon, 11 May 2020 10:44:00 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 49CF43004AF for <sidrops@ietf.org>; Mon, 11 May 2020 10:44:00 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\))
Date: Mon, 11 May 2020 10:44:01 -0400
References: <m2mu6f42ji.wl-randy@psg.com> <B23AED42-5983-4E14-897A-03A51FCDDC42@nlnetlabs.nl> <m2zhae3hrh.wl-randy@psg.com> <20200511123331.5c2d604a@glaurung.nlnetlabs.nl> <73D1F29B-7F54-4022-975C-477B3A9E7CC5@psg.com> <20200511125957.09b5f5e5@glaurung.nlnetlabs.nl> <m2y2py3emb.wl-randy@psg.com>
To: SIDR Operations WG <sidrops@ietf.org>
In-Reply-To: <m2y2py3emb.wl-randy@psg.com>
Message-Id: <FA1358BC-54C0-476B-A8A0-238D2F4EFE74@vigilsec.com>
X-Mailer: Apple Mail (2.3445.104.14)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/qZTlN_CvngMLulCrsO1j0yjh51U>
Subject: Re: [Sidrops] nlnet rp and rsync
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, 11 May 2020 14:44:09 -0000

The repository MUST be available by rsync, and it MAY also be available using other protocols.

A client can use any of the protocols that it wants, but it seems like unnecessary fragility to pick an alternate and then refuse to consider rsync.  This seem counter to a graceful transition, especially if there is a transition from RRDP to RRDP2 in the distant future.

Russ


> On May 11, 2020, at 7:17 AM, Randy Bush <randy@psg.com> wrote:
> 
> turning a private discussion public, with consent of course
> 
> it turns out that, to quote tim
> 
>> Routinator has had support for RRDP since version 0.6.0, released in
>> September 2019.
>> 
>> If it finds an RRDP SIA and successfully synchronizes the publication
>> point once, it will whitelist the RRDP SIA URI and it will no longer
>> fall back to rsync where this URI occurs on CA certificates. As long
>> as the synchronization has not been successful it will fall back to
>> rsync.
> 
> to which i then said
> 
>> that seem a potential violation of spec.  if the PP RRDP service then
>> fails, it really MUST fall back to the mandatory to implement rsync.
>> 
>>> As long as the synchronization has not been successful it will fall
>>> back to rsync.
>> 
>> s/As long as/If/
> 
> to which martin said
> 
>> Can you point me to where it says that? Section 3.4.5 of RFC 8182 is
>> pretty indifferent about it.
> 
> to which i said
> 
>> among other places, 6481 s3
>> 
>>     *  The publication repository MUST be available using rsync
>>        [RFC5781] [RSYNC].  Support of additional retrieval mechanisms
>>        is the choice of the repository operator.  The supported
>>        retrieval mechanisms MUST be consistent with the accessMethod
>>        element value(s) specified in the SIA of the associated CA or
>>        EE certificate.
> 
> to which martin responded
> 
>> This talks about what the publication point has to offer, not what a
>> cache has to use. In particular, it says that the publication point
>> musn’t advertise RRDP unless it actually offers RRDP. Which means that
>> as a cache I can rely on RRDP being available.
>> 
>> Forcing a cache to use rsync instead of RRDP is a downgrade attack and
>> should be handled accordingly.
> 
> at which point i said it is time to take this to the wg.  so here we go.
> 
> imiho, 6481 makes it very clear that rsync is currently the mandatory to
> implement protocol (yes i am a coauthor of a draft trying to eventially
> change that).  i contend that this is MTI by both the publisher and by
> the client.
> 
> randy
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops