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

[Job Snijders <[e-mail]>]

On Tue, Jun 25, 2024 at 03:44:15PM +0200, Martin Hoffmann wrote:
> Job Snijders wrote:
> > 
> > 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 figure we can reasonably trust (ha!) TA operators to be careful.

I'd like that too, but I figured that aiming for robustness on both
sides of the TA <> RP communication channel is desirable.

> > 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.
> 
> It’s not really complete though, since you still have the case that both
> notBefore and notAfter are identical. So you still need to define what
> happens if you have two different certificates with identical times.
> 
> Worse, if you have identical notBefore dates but differing notAfter
> dates, you need to make an arbitrary choice which one of the two
> certificates you choose. There just isn’t a “clearly it’s this one”
> kind of answer.

Based on feedback from Tim Bruijnzeels I incorporated an extra step to
be published in the next revision of this internet draft: 

https://github.com/job/draft-sidrops-rpki-ta-tiebreaker/commit/957080b9c279494564dd06e7bcaf714d7acb4c06

The idea is that if the signature is valid, the public key matches, the
validity period exactly matches, then the final step is to just use the
newly-retrieved certificate. In that case we base 'recency' off the
recency of the network fetch. All things considered equal, use the
latest one fetched over the network.

> So having this additional check doesn’t provide extra safety. I want to
> argue that if there’s no benefit, leave it out.

I believe that specifying a preference for shorter validity periods
helps improve the agility of the system.

Again, I agree with you that in almost all cases just using notBefore is
sufficient to make a good decision, but in case a notBefore for one
reason or another is 'frozen in time' can be addressed by looking at the
notAfter, and if that one also is the same, then and only then just use
the newly retrieved object (assuming the crypto checks out)

> > 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.
> 
> I still wouldn’t want to use rsync unless HTTPS doesn’t work -- if only
> to keep the rsync load on TA operators at a minimum. Whether we should
> suggest to randomize URIs (of the same type) is a question I’d would
> like some input from the TA operators from. Given that currently there
> is always exactly one HTTPS URI and exactly one rsync URI, it’s all a
> bit academic. If the operators say that they want to keep it that way,
> I’d rather not have to have randomizing code that isn’t actually ever
> used.

I agree, as I mentioned in my previous email, rpki-client prefers HTTPS,
and if there is an issue at the transport layer will fall back to rsync.
An open question is whether we should add some trickery that in case
the HTTPS fetch was successful but the object retrieved was garbage,
whether to try rsync, or use the locally cached copy and wait for the
next validation cycle.

I too would love to hear TA operator preferences in this regard.

Kind regards,

Job