Re: [Sidrops] [[e-mail]: New Version Notification for draft-spaghetti-sidrops-cms-signing-time-00.txt]

[Ties de Kock <[e-mail]>]

Hi Job,

> On 8 Jun 2023, at 15:34, Job Snijders <[e-mail]> wrote:
> 
> On Thu, Jun 08, 2023 at 12:15:24PM +0200, Ties de Kock wrote:
>> There is one edge case in this behaviour that a mail from Tom made me
>> think off. It is far-fetched, but given that rsync not fetching a file
>> likely breaks a repository (and at a publication point that is likely
>> to have many updates, so high in the tree), I think it is worth
>> considering.
> 
> I think the case you describe is not at all a concern, please read on
> for some notes why I think so.
> 
>> It is similar to [0]: Multiple updates for an object per second (most
>> likely due to automation) can occur. They can occur in any timestamp
>> in the object.
> 
> There is a source of entropy to consider: for Signed Objects the
> recommendation is for the filename to be derived from the associated
> one-time-use EE certificate's public key (RFC 6481 section 2.2). This
> means that if for example for the same prefix multiple ROAs are
> added/deleted, multiple different files will be added to the manifest
> and removed from the manifest.

My understanding is that not all (RIR) CAs are using one-time-use EE
certificates. If all CAs used one-time-use EE certificate, things would be
easier.

> Manifests, CRLs, and CA certificates have persistent names: this implies
> that a reissued mft/ca/crl overwrites a previously issued mft/ca/crl (to
> the same subject) in the publication repository.
> 
> If the CA issues multiple manifests/crls each with the exact same
> filesize as the previous one within the same second (all in all a
> situation which could be considered misissuance under current
> guidelines), the RP indeed might end up using the first issued Manifest,
> instead of the second or third one issued that second.
> 
> I don't view this as a problem: after all the manifest /was/ issued. If
> a CA issues something, the CA should expect some RPs to end up using it.
> 
> Between the innate entropy in the filenames (new filename means new
> transfer), RPs being recommended to use locally cached versions of
> objects [RFC 9286] to supplement construction of states, and RPs
> periodically (within 10 ~ 60 minutes) resyncing, ending up with the
> first (valid) manifest in a 'same second issuance' is no concern to me.

The issue is in this type of ordering of events:
  * Publication {manifest_1, roa_1}, roa_1 is on manifest_1
  * repository write starts at this point on timeline
  * Publication {manifest_2, obj_2} in the same second
  * Publication {other_file_1, manifest_3} some time later
  * An RP retrieves {manifest_1, obj_1}, obj_1 is on manifest_1

  * repository written to disk at this point on timeline
  * An RP retrieves {manifest_3, other_file_1}, obj_2 is not fetched but on manifest, failed fetch.

w.l.o.g. the same applies for certificates from a child CA.

> 
>> Do we want to consider the time-collision case? Do we want to aim to
>> have a deterministic modification time resistant to collisions?
> 
> I have considered it but it seems an unnecessary complication for no
> obvious benefit. To me the mod-time / CMS signing-time is just a
> monotonically increasing parameter.
> 
> While a CA indeed might (mis?)issue multiple objects for the same
> timestamp, ultimately it is incumbent upon the CA/Publisher to present a
> set of files in a hierarchy that is internally consistent and moved into
> the publication point via an atomic operation.

The repository as published is consistent. rsync fails to fetch the new files
because it uses the wrong comparison.

> The use of CMS signing-time as a means to normalize filesystem last
> modified timestamps in order to reduce the burden of initial
> synchronization after RRDP to RSYNC failover doesn't change that.
> 
> We've now sent quite some emails back and forth on this topic, but it is
> not entirely clear to me what your position on
> draft-spaghetti-sidrops-cms-signing-time is, so I'll just ask - is the
> proposed approach something you'd be willing to consider implementing?


I think standardising on signing-time and removing binary signing time is a
reduction in complexity and removes ambiguity in interpretation of RPKI
standards. Strong support there.

We have implemented equivalent logic (using notBefore, but notBefore==signingtime)
for the RIPE NCC CA. But now that these discussions caused us to think more
about the edge-cases it makes me uneasy. Very rare issues happen in reality and
do have real world effects.

If we find an approach without a collision problem, I would recommend
implementing it. As is, I do not feel it is safe to have the MUST in section
2.1.

Kind regards,
Ties