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

[Job Snijders <[e-mail]>]

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.

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