Job, Thanks for the explanation. It is nice to know that TAK is in addition to the conventional methods (emails/website, etc.) See more comments below: -----Original Message----- From: Job Snijders <job@xxxxxxxxxx> Sent: Monday, April 29, 2024 3:38 PM To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> Cc: secdir@xxxxxxxx; draft-ietf-sidrops-signed-tal.all@xxxxxxxx; last-call@xxxxxxxx; sidrops@xxxxxxxx Subject: Re: [Last-Call] Secdir last call review of draft-ietf-sidrops-signed-tal-15 Dear Linda, On Mon, Apr 29, 2024 at 03:25:26PM -0700, Linda Dunbar via Datatracker wrote: > Summary: This document introduces an in-band notification of Key > Updates for notifying RPs of the updates to a Trust Anchor Locator > (TAL) and distribution of TAL Data via TAK Objects. yes, that's a good summary. > While this in-band notification allows for more dynamic management of > keys and helps ensure RPs are aware of key rollovers, it introduces a > single point of failure. TAK objects don't introduce a single point of failure. In fact, the Signed TAL mechanism introduces *additional* means of communicating updates about new TALs to the RP community (in addition to email, websites, github pull requests, social media, etc) - with the primary advantage that TAK object are signed with signatures verifyable within the RPKI context itself. [Linda] It would be nice to add this sentence to the Security Consideration. Another question: What if those multiple methods are not consistent? > Suggest to add some description in the Security Consideration on what > happens when the in-band mechanism is compromised. In the RPKI hierarchical context, a Trust Anchor is an authority for which trust is assumed and not derived. "Assuming trust" means that violation of that trust is out-of-scope for the threat model. The relationship from the RP to the Trust Anchor and from there to the Trust Anchor Key is one of such "assumed trust" arcs. The signed-tal draft does nothing to improve or worsen the situation related to in-band mechanisms being compromised. TAK objects cannot be used to repair compromised in-band mechanisms, nor prevent compromise. Perhaps it is helpful to imagine the use-cases for TAK objects being more in the mundane: facilitating a change of URLs, or a keyrollover to a new cipher algorithm. [Linda] Yes, your explanation helps a lot. It would be nice to add your explanation to the Security Consideration, Hope this clarifies a bit! Kind regards, Job -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
