Tom, Thanks for the changes to the draft. It is great. Linda -----Original Message----- From: Tom Harrison <tomh@xxxxxxxxx> Sent: Monday, May 6, 2024 4:10 AM To: Linda Dunbar <linda.dunbar@xxxxxxxxxxxxx> Cc: Job Snijders <job@xxxxxxxxxx>; secdir@xxxxxxxx; draft-ietf-sidrops-signed-tal.all@xxxxxxxx; last-call@xxxxxxxx; sidrops@xxxxxxxx Subject: Re: [Sidrops] [Last-Call] Secdir last call review of draft-ietf-sidrops-signed-tal-15 Hi Linda, Thanks for this review. On Tue, Apr 30, 2024 at 06:46:47AM +0000, Linda Dunbar wrote: > 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 > > On Mon, Apr 29, 2024 at 03:25:26PM -0700, Linda Dunbar via Datatracker wrote: >> 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. This content has been added to the security considerations. [Linda] Thanks. > Another question: What if those multiple methods are not consistent? If the TA is going through a transition, then so long as the RP gets either the current key or the new key through one of the available methods, then the RP will end up at the new key eventually, if it takes account of TAK objects in some way. Some text about this has been added to the security considerations. [Linda] that will be great! >> 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, This content has been added to the security considerations. Please see attached for an updated document and a HTML diff for the new changes. -Tom -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
