Re: [Sidrops] Paul Wouters' Yes on draft-ietf-sidrops-cms-signing-time-07: (with COMMENT)

[Job Snijders <[e-mail]>]

Dear Paul,

Thank you for taking the time to review this document!

On Wed, Apr 17, 2024 at 10:08:24AM -0700, Paul Wouters via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> The abstract seems overly long and best moved to the Introduction. I would only
> keep the last paragraph of the Abstract. Although it seems already mostly
> repeated in the Introduction so just removing the first two paragraphs would
> probably be good as well.

Based on earlier feedback from your colleagues I updated the abstract
yesterday. Please see here for the difference. 

https://author-tools.ietf.org/iddiff?url1=draft-ietf-sidrops-cms-signing-time-06&url2=draft-ietf-sidrops-cms-signing-time-07&difftype=--html

Does this work for you?

>         This document advances the aforementioned concept
> 
> Advance from what to what? I think you mean "from optional to mandatory" ?

The intention was to signal there is an 'innovation' in this document:
I-D.timbru-sidrops-publication-server-bcp suggests to only update the
timestamp if the file is changed, note that it doesn't matter what
timestamp is used.

However, draft-ietf-sidrops-cms-signing-time takes this one step further
and suggests to use a specific timestamp (calculated from a timestamp
inside the file), because that allows RPs to do a seamless switchover
from RRDP to rsync, without needless retransfers, without ever haven
synchronized via rsync before.

> In section 2.2, it talks about omitting transfers and sparse backups, but it
> does not mention it creates hardlinks for files that need no transfering from
> the reference directory, at least how I use rsync, eg with --archive which
> means "-rlptgoD". (this is fact the way I still do backups, creating daily
> trees that are full directory sets per day all using hardlinks for unmodified
> files). With this option, it does the things the document talks about, like
> using original datestamp, perms, modes, etc.

Using '-a' in context of the RPKI would be *strongly* inadvisable, as
this would could lead to rsync to copying executable files, perhaps even
with the suid bit set as root. Combined with another issue, this could
easily lead to privilege escalation.

The rsync --compare-dest option does not create hardlinks.

Keep in mind that the copy happens across trust domain boundaries: from
the RP's perspective, the remote rsync server represents untrusted,
potentially hostile, network input.

The OpenBSD RP implementation uses these rsync options:

$ rsync -rtO --no-motd --min-size=100 --max-size=4000000 \
    --contimeout=15 --timeout=30 \
    --include=* --include=*.cer --include=*.crl --include=*.gbr \
    --include=*.mft --include=*.roa --include=*.asa --include=*.tak \
    --include=*.spl --exclude=* \
    --compare-dest ../../../rpki.ripe.net/repository \
    rsync://rpki.ripe.net/repository .rsync/rpki.ripe.net/repository

The result of the above command is that the *difference* between the
(previously validated) content in '../../../rpki.ripe.net/repository'
and the remote server, is stored in '.rsync/rpki.ripe.net/repository'.

Additionally, the command helps transfer only files that the validator
can actually parse (RPs don't want to download .iso files), and helps
reject files that are too small or too large, and avoids transferring
empty directories. '--delete' is not used, because filesystem cleanup
can be performed using cryptographically signed data derived from the
RPKI itself.

The validator will then validate the data in
'.rsync/rpki.ripe.net/repository' according to the RPKI standards, and
optionally move files from .rsync/rpki.ripe.net/repository to
../../../rpki.ripe.net/repository if they present a valid newer version,
or continue use the 'older' (valid) version in
../../../rpki.ripe.net/repository, if there is some issue with the newly
transferred version of a given file.

See RFC 9286 section 6 and
https://www.ietf.org/archive/id/draft-harrison-sidrops-manifest-numbers-01.html#name-walkthrough-of-the-rpki-cli
a more elaborate description of how RPs can decide between accepting the
purported new version from the remote side, or continue using a locally
cached object.

In short, the only thing worth preserving from the remote side are the
timestamp on files, the directory hierarchy (but not the directory
timestamps), and the file data itself.

Does the above elaboration help clarify?

Kind regards,

Job