Re: [Sidrops] trying to limit RP processing variability

[Job Snijders <[e-mail]>]

On Wed, Apr 15, 2020 at 11:49:55AM -0400, Jay Borkenhagen wrote:
> Job Snijders writes:
>  > On Wed, Apr 15, 2020, at 12:46, Martin Hoffmann wrote:
>  > > An attacker who can delete files can as easily replace them with
>  > > something else with the same result. So I am not sure the added code
>  > > complexity is worth it.
>  > 
>  > Agreed. 
>  > 
>  > fwiw: rpki-client runs as "openrsync -rlt --delete rsync://xxx/repository xxx/repository"
>  > 
> 
> I agree with this behavior as well.

I think I was wrong to agree here. I had discussions with some people
about 'where does the publication point exist?' - is it a remote entity?
or is a local construction of pulled data? I'm now leaning more towards
an interpretation that the publication point only exists in the mind of
the RP.

Phrased differently: It seems somewhat strange to let unauthenticated
untrusted network data (aka 'rsync --delete') destroy an otherwise
perfectly healthy and valid CA.

What perhaps should be done:

- rsync pulls data in (without '--delete')
- the validation process deletes files that are not listed on the valid
  manifest (iff a valid contemporaneous CRL exists)
- Additionally, implementers will need to pull the untrusted RPKI data
  into a staging area, to guard against letting the rsync overwrite
  otherwise healthy .roa files with garbage.

Kind regards,

Job