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

Hi Job,

> On 21 Oct 2022, at 15:47, Job Snijders <job=40fastly.com@dmarc.ietf.org> wrote:
> 
> Dear all,
> 
> I implemented draft-ietf-sidrops-signed-tal-12 in OpenBSD's RPKI
> validator. More information about this RP implementation is available
> at: https://www.rpki-client.org/
> 
> The 'Signed TAL' software implementation changeset can be found here:
> https://marc.info/?l=openbsd-tech&m=166635746808783&w=2
> 
> 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 <job@fastly.com>
> 
> Feedback:
> 
>   Overall I found the document easy to read and straight-forward to
> implement. Tom Harrison's testbed was very useful in producing the above
> mentioned changeset. I very much appreciate the quick back-and-forths
> which helped resolve bugs on either side.
> 
> 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.

I think that an analysis and discussion of the additional risk introduced by
automated transition between certificates is very much needed.

Operational choices after loss of posession, or loss of control of a key is a
separate discussion.

> 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.

I would object to the word _certified_ being added here. This will end in
control frameworks, while all _implementations_ of certified destruction that I
have read about have certified drawbacks.

> 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.

There are two use-cases for TAK. There is the signalling out of band of usage of
a new key, and automated transitioning between keys. For the latter, support
from the majority of running RP instances is needed.

I think your position is about the out of band distribution?

Kind regards,
Ties
> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops