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

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 1 Sep 2020 10:18:30 +0200

Hi all,

I just submitted this as WG document per request by the chairs on July 16.

The issues that I think could be most controversial are:

1) rsync URIs as object identifiers (section 4)

In summary: the document proposes that we keep rsync URI as useful object identifiers even if the objects cannot be retrieved at that location. The main reason for this is pragmatism: introducing a new kind of object identifier (e.g. URN based) would introduce a breaking change and make deployment much, much harder.

2) rsync still allowed

Currently the document says (tries to say) that if operators want, they can still leave an rsync server running. While they are not required to do so, it is not forbidden either.

3) rsync URIs in RRDP - can they be trusted?

Finally, we recently had a discussion related to manifests (6484-bis) and a concern was raised that the rsync URIs in the RRDP XML cannot be trusted. I also took this to the list on 25 June (subject RRDP and rsync URIs). But for clarity I think it's best to continue to discuss here.

While it may seem odd that the rsync URIs could be for different hosts than the RRDP base URI, my main original motivation for allowing this in RRDP was to provide CDN support. The Publication Server may outsource its HTTPS function to a CDN, but it may not possible for this CDN to handle or forward rsync requests.

While any RRDP server can include any rsync URI in the <publish> and <withdraw> elements in its XML, this is not really an issue because relying parties know both the rsync URI *and* the RRDP server when validating - so they can look for the rsync URI at the relevant RRDP server only.

The Publication Server (PS) is supposed to let its publisher publish under a base uri only (RFC8181 and 8183). None of this is changed. In principle the PS can have bugs, or do a poor job of checking this. But they are already able to mess things up when we have rsync only. Because of the compound URI (RRDP + rsync) there is no new attack vector opened this way.

Kind regards,
Tim

> On 31 Aug 2020, at 21:05, [email-masked] wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the SIDR Operations WG of the IETF.
> 
>        Title           : Resource Public Key Infrastructure (RPKI) Repository Requirements
>        Authors         : Tim Bruijnzeels
>                          Randy Bush
>                          George Michaelson
> 	Filename        : draft-ietf-sidrops-deprecate-rsync-00.txt
> 	Pages           : 10
> 	Date            : 2020-08-31
> 
> Abstract:
>   This document formulates a plan of a phased transition to a state
>   where RPKI repositories and Relying Party software performing RPKI
>   Validation will use the RPKI Repository Delta Protocol (RRDP)
>   [RFC8182] as the only mandatory to implement access protocol.
> 
>   In short this plan consists of the following phases.
> 
>   In phase 0, today's deployment, RRDP is supported by most, but not
>   all Repositories, and most but not all RP software.
> 
>   In the proposed phase 1 RRDP will become mandatory to implement for
>   Repositories, in addition to rsync.  This phase can start as soon as
>   this document is published.
> 
>   Once the proposed updates are implemented by all Repositories phase 2
>   will start.  In this phase RRDP will become mandatory to implement
>   for all RP software, and rsync must no longer be used.
> 
>   Measurements will need to be done to help determine when it will be
>   safe to transition to the final phase of this plan.  During this
>   phase Repositories will no longer be required to provide rsync access
>   for RPKI validation purposes.  However, they may still provide rsync
>   access for direct access to files for other purposes, if desired, at
>   a best effort basis.
> 
>   Although this document currently includes descriptions and updates to
>   RFCs for each of these phases, we may find that it will be beneficial
>   to have separate documents for the plan, and each phase, so that it
>   might be more clear to all when the updates to RFCs take effect.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-sidrops-deprecate-rsync/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-sidrops-deprecate-rsync-00
> https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-deprecate-rsync-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: George Michaelson <[email-masked]>
Date: Wed, 2 Sep 2020 09:27:04 +1000

Purely on aesthetics, and personal drive, I would prefer we change the
"handles" which are rsync URI to be something else, preferably the
HTTPS path to the object. I understand why people don't want to do
this, but I would have chosen this path, had we not arrived at the
point in time where the volume of RPs is non-trivial. The delay
deciding on this has magnified the problem.

This kind of thing has been discussed: people hate flag dates. OTOH,
they never get easier by delaying.

But, your comment about this being a breaking change for RPs is well made.

-G

---

From: Russ Housley <[email-masked]>
Date: Fri, 4 Sep 2020 11:40:07 -0400

Tim:

I think that RFC 6487 should also be updated to adjust the RPKI certificate profile.  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.

Russ

> On Sep 1, 2020, at 4:18 AM, Tim Bruijnzeels <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 4 Sep 2020 22:10:22 +0200

Hi Russ,

On 4 Sep 2020, at 17:40, Russ Housley <[email-masked]> 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.

>  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:

RFC6487: allow https URIs, or URNs maybe

RFC8183: Repository Response, replace rsync base uri
RFC8181: Publication Protocol, no more rsync uris
RFC8182: RRDP, includes rsync uris - replace

RFC6492: 'up-down': Let CAs request certs with other URI types

New OIDs mean that all RPs treat objects as invalid. Essentially all RPs would have to support the new OIDs before anything can be deployed by CAs - or they will reject all publication points. Child CAs can only deploy when parents support. Extending RFC8181 and 6492 will mean multiple versions.

If we really do need to go down this path, then I believe that this exceeds the possible scope of this single document. And if we do *all* this, then we should probably stop to think first about whether current repository structure, and RRDP (which tried to follow rsync as close as possible) are really what we want then.

So, in short I would then suggest that we do this as a separate effort. And we live with rsync URIs as namespaces for a while. Then at least the operational burdens can be reduced while we figure out how to solve it completely.

Tim

---

From: Russ Housley <[email-masked]>
Date: Fri, 4 Sep 2020 16:34:16 -0400

> 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 server…

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.

> 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

---

From: Tim Bruijnzeels <[email-masked]>
Date: Mon, 7 Sep 2020 14:42:51 +0200

Hi,

> On 4 Sep 2020, at 22:34, Russ Housley <[email-masked]> wrote:
> 
> Tim:
> 

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