Re: [Sidrops] Implementation report for draft-ietf-sidrops-signed-tal-12

[Tom Harrison <[e-mail]>]

Hi Job,

Your feedback and implementation work here are very helpful and much
appreciated, thanks.

On Fri, Oct 21, 2022 at 03:47:56PM +0200, Job Snijders wrote:
> Please add to Section 12 "Implementation Status":
> 
>    Responsible Organization: Job Snijders
>    Location: https://marc.info/?l=openbsd-tech&m=166635746808783&w=2
>    Description: A relying party implementation which can validate TAKs.
>    Level of Maturity: Mature. Trust Anchor operators are encouraged to
>       use rpki-client as part of smoke testing to help ensure high
>       levels of standards compliance when introducing changes, and use
>       rpki-client in a continuous monitoring fashion to help maintain
>       high levels of operational excellence.
>    Coverage: implementation includes all features except TAK acceptance
>       timers.
>    Contact information: Job Snijders <[e-mail]>

Thanks, we'll add this to the document.

> Notes to the internet-draft authors:
> 
> 1/ Section 10.2 "TA Compromise" makes no sense to me. I'd like to
>    suggest to remove section 10.2 entirely. There is no such thing as an
>    adversary 'temporarily' being in control of Trust Anchor private key
>    material. Once a TA is discovered to be compromised, this discovery
>    should be widely announced (NANOG, RIPE Routing-WG, SIDROPS, etc);
>    and the community immediately should get to work to remove all TALs
>    pointing to the compromised TA (both in RP implementations, as well
>    in operating systems that bundle RPKI roots in a generic fashion such
>    as Debian/Ubuntu/OpenBSD/etc). However, organisation of responses to
>    TA compromise are out-of-scope for the signed-tal internet-draft.
> 
> 2/ Section 10.3: s/can be complementary/are complementary/
> 
> 3/ Section 11 lacks a Media Type registration. See RSC for an example:
>    https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc#section-10.5
> 
> 4/ Section 10.1 should also mention certified destruction of
>    previously-current keypair materials.
> 
> 5/ Section 9 states "can only be relied on once a majority of RPs
>    support it". I don't believe concepts like 'herd immunity' apply in
>    this case, for example in the case of OpenBSD or Debian (where RPKI
>    roots are available to the system operator as non-RP-specific
>    manner); only the packager of the RPKI roots needs to be able to
>    support, and all Debian/OpenBSD users subsequently benefit from that
>    support being downstream. In other words, there are benefits to TAK
>    even if only a very small percentage of RPs support it.

We take your points here, and will make updates to address each of
them.  Some discussion of these during the next meeting may be useful,
too.

-Tom