[Sidrops] Re: Notification for draft-spaghetti-sidrops-rpki-ta-tiebreaker

[Job Snijders <[e-mail]>]

Dear Martin,

On Tue, Jun 25, 2024 at 12:06:20PM +0200, Martin Hoffmann wrote:
> Job Snijders wrote:
> > 
> > Tim and I had a meeting and talked this draft over, Tim suggested to
> > remove the notion of 'local policy' (as this introduces ambiguity).
> > Instead: if the validity period is considered equal, and the signature
> > is good, use the newly-retrieved cert (if it differs from the locally
> > cached copy).
> 
> Given that the aim here is to avoid replaying (either maliciously or
> accidentally) an older certificate and that we can trust that TA
> operators take a fair amount of care, I think only looking at notBefore
> time and using the new certificate if it is greater or equal should be
> good enough. As a safeguard, you could add a line instructing TA
> operators to never issue TA certificates with identical notBefore.

An argument in favor of also looking at notAfter is that it is possible
for CAs to 'freeze' the notBefore at a given point in time, meaning that
in subsequent issuances the same notBefore continues to appear. I've
seen some RPKI CAs (unsure about TAs) exhibit this behaviour.

I'd also argue that defining a 'complete' tiebreaker procedure at the
small expense of having a handful of sentences and 4 lines of code* is
worth it to cover for the edge case of TAs issuing with identical
notBefore's.

*4 lines, ymmv: https://github.com/openbsd/src/blob/master/usr.sbin/rpki-client/parser.c#L619-L622

I don't see downside to using both notBefore and notAfter, but yes,
strictly speaking notBefore probably is sufficient most of the time.
This is why the notBefore tiebreaker should be the first tiebreaker.

> One thing to possibly consider to make it more unlikely that a new
> certificate is withheld (again either maliciously or accidentally) is
> to require trying different URIs listed on the TAL if the fetched
> certificate is rejected for any of the reasons in the list and only use
> the stored certificate if all of them are rejected.
>
> Routinator currently doesn’t do that -- it uses a stored certificate
> for that particular URI if fetching a new one fails --, but that’s
> mostly because we don’t want to fall back from the safer HTTPS
> transport to rsync where replaying an old certificate is easier. But
> with the proposed protection mechanism, this won’t be necessary any
> more.

That's a nice idea. Rpki-client tries HTTPS first, if HTTPS fails (TLS
error, HTTP error) it will try rsync. But it won't try rsync if the HTTP
code was 200. Another approach is to pick a random URI from the TAL (be
it HTTPS or rsync), because with the proposed protection mechanism rsync
becomes less risky. Picking a random URI from the TAL has the benefit
that if they are hosted on different FQDNs, overall resilliency increases.

So I guess we have 2 options:

- try different URI if the newly fetched TA cert has an issue
  (regression or siganture-wise)
- try a random URI, and if there was an issue use the local cache

Do you have a preference?

Kind regards,

Job