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

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

On Tue, 25 Jun 2024 at 07:56, Job Snijders
<job=[e-mail]> wrote:
>
> Dear Dale,
>
> On Mon, Jun 24, 2024 at 12:07:04PM -0500, Dale W. Carder wrote:
> > Thus spake Job Snijders (job=[e-mail]) on Mon, Jun 24, 2024 at 02:34:39PM +0200:
> > > 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).
> > >
> > > I incorporated this feedback in my edit buffer:
> > > https://github.com/job/draft-sidrops-rpki-ta-tiebreaker/commit/957080b9c279494564dd06e7bcaf714d7acb4c06
> >
> > As I read through -00, would it make sense for an implementation to
> > apply the tiebreaking only after other (local) validity checks pass?
> > If one TA object passes and the other fails, it would seem you don't
> > have a tie to break?
>
> In the abstract you might be right, but the issue is that we (me, Tim,
> others) have no idea what 'other local validity checks' practically
> speaking means. I'm not aware of any Relying Party implementation that
> "Perform other checks" in the manner that RFC 8630 describes.

I just recalled a local policy.

The RIPE NCC RPKI validator used to check that the serial number of the
certificate was higher than the one on the current certificate. I recall
this local policy because it caused problems, a new cert had a lower serial,
likely the case explained in [0].

You can probably also describe the variations between TLS libraries in how they
handle certificates as local policy.

I do not see a need to call this out. It just causes uncertainty
("is there anything I _need_ to add here?").

Kind regards,
Ties:

[0]: https://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt -
specifically a serial number with the highest bit set.

>
> If one TA object fails (for example, the newly retrieved object has an
> incorrect signature), then indeed there is no tie to break and the RP
> should use the previously fetched locally cached copy.
>
> > As tiebreaker-00 updates rfc8630 section 3, does there need to be
> > adjustment to the 8630 text beyond those numbered list items?  Does
> > the tiebreaking also apply in the case of multiple TA's in the TAL,
> > (would you want to grab them all and do the above logic) or is this
> > case different?
>
> If a TAL contains multiple URIs, all those URIs are supposed point to
> the same TA certificate object. RFC 8630 states "Where the TAL contains
> two or more TA URIs, the same self-signed CA certificate MUST be found
> at each referenced location."
>
> While it is technically trivial for RPs to fetch all URIs and confirm
> the fetched objects indeed are the same, and then run a process to
> select a candidate from the newly retrieved and locally cached copy, it
> would also double the network traffic for this operation. So far RP
> implementers have interpreted the presence of multiple URIs in a TAL to
> be for redundancy: if the HTTPS fetch fails, try rsync.
>
> I've not yet spotted more things in 8630 to update, but it is a fair
> question whether to do an 'update'-draft or a '-bis'-draft. I view as
> advantage of draft-ta-tiebreaker that it is a local-only improvement,
> doesn't change the TAL format/concept, and in that sense backwards
> compatible.
>
> Can you think of anything else you'd like to change in RFC 8630?
>
> Kind regards,
>
> Job
>
> _______________________________________________
> Sidrops mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]