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

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

Hi all,


On Tue, 25 Jun 2024 at 17:11, Job Snijders
<job=[e-mail]> wrote:
>
> 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.

I like that this now defines a full order, and allows operators to always
publish a more specific certificate that RPs will prefer.

> 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 see potential operational situations in which one of the certificates is
updated but the other is not. A TA operator should monitor this. By running an
RP with an empty state, and a TAL with just the rsync, or just the https URL at
a set interval, the operator can check that the currently published
objects make sense.

@Job: This feels obvious, but might be good to add.

Assuming that the monitoring above is done when a successful HTTPS connection
retrieves a certificate that is not valid/not preferred over the current
certificate, I would not retry via rsync. A TA should monitor for the and have
process controls for the operational mistakes. Furthermore, an on-path attacker
(with a valid TLS cert even!) could attack rsync as well.

If this document becomes a -bis, it might be good to consider how we handle TA
certificates in the RRDP publication point the trust anchor certificate points
to. That could prove to be an interesting update mechanism.

Kind regards,
Ties