[arin-ppml] Revisit RPKI TAL Relying Party Agreement?

[Job Snijders]

Dear ARIN Board of Trustees, staff, and community!

Reviving an old thread, I’d still like this to be resolved :-)

It is my understanding that the ARIN RPKI TAL currently is a hot topic for
the Board of Trustees. I can see a lot of effort is being put in to get to
a point to make a fully informed decision, which I appreciate. My hope is
that - somehow - the ARIN RPKI TAL can become more like other public key
files which we embed in our systems to improve our lives.

I shot a video to illustrate some analogies I see between DNSSEC, TLS,
Signify, and RPKI. The purpose of the video is to show that you can install
and boot a fully functional operating system without agreeing to anything
that resembles something along the lines of the ARIN RPA.

Video link: https://youtu.be/oBwAQep7Q7o (11 minutes)

Kind regards,

Job

On Mon, 30 Jan 2017 at 17:42, Job Snijders <job at ntt.net> wrote:

> Dear all,
>
> For many years now, the publication of ARIN's cryptographic RPKI
> materials has been a point of contention. See [1], [2], [3], and [4] as
> examples of the ongoing discussion.
>
> Third parties who wish to validate BGP route announcements to protect
> their ARIN-region-based customers and partners, or to use RPKI data in
> provisioning processes (such as prefix-filters generation), must
> (implicitly) agree to the "Relying Party Agreement".
>
> From https://www.arin.net/resources/rpki/tal.html:
>
>     "ARIN publishes all Certificates, Certificate Revocation Lists
>     (CRLs), and RPKI-signed objects in its Resource Public Key
>     Infrastructure (RPKI) Repository. The ARIN Repository is available
>     to anyone under the terms and conditions in the Relying Party
>     Agreement."
>
> These materials are intended to be used by both ARIN members as well as
> non-ARIN affiliated organisations (who might not even have a presence in
> the ARIN region).
>
> What stands out to me is that (as example) the RIPE NCC RPKI Validator
> ships with materials from all the RIRs, except ARIN. The RPKI Validator
> is a commonly used software package to interact with the RPKI.
>
>
> https://github.com/RIPE-NCC/rpki-validator/tree/master/rpki-validator-app/conf/tal
>     (notice that LACNIC, AfriNIC, APNIC, RIPE NCC are all there)
>
> As such, the RPKI Validator (out of the box) is not complete. I
> attribute this to ARIN's RPA. This phenomenon puts a burden on every
> organisation wishing to use RPKI.
>
> I view this as a shortcoming of the ecosystem and detrimental to our
> efforts maintain a secure routing system.
>
> Of course any party can read the RPA and (if they agree) download the
> ARIN TAL and add it to their RPKI Validator installation, but I strongly
> prefer an ecosystem which out-of-the-box is operating in a secure mode.
> I'd argue that ARIN has an obligation to its members to make these
> materials unencumbered by legal constraints and freely available to
> anyone.
>
> A comparison can be drawn with DNSSEC: ICANN (through the IANA) go above
> and beyond to publish the DNSSEC materials required for validation, and
> ensure distribution as widely as possible:
> https://www.iana.org/dnssec/files
> The strategy is described here:
> http://data.iana.org/root-anchors/draft-icann-dnssec-trust-anchor.html
> Note that there is no mention of "Agreement" or "Indemnification".
> Imagine DNSSEC without trivial availability of public keys: it wouldn't
> work.
>
> I'd like to request that we revisit the topic of the RPKI TAL Relying
> Party Agreement, with the goal to make these cryptographic materials
> freely available in such a way that they can be bundled with software
> distributions. When ARIN's TAL can be bundled freely, I anticipate more
> innovation in the secure routing problem space. RPKI can play a
> significant role in not only as a defense mechanism, but also as part of
> provisioning processes. Unlimited distribution of the RPKI TALs is key.
>
> I consider the limited availability of the ARIN TAL a showstopper for
> global RPKI deployment.
>
> Kind regards,
>
> Job Snijders
>
> [1]: http://seclists.org/nanog/2016/Feb/84
> [2]: http://seclists.org/nanog/2014/Dec/77
> [3]: http://packetpushers.net/rpki-bgp-security-hammpered-legal-agreement/
> [4]: http://markmail.org/message/ycbijxzgw24je5zn
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20191021/cb9ff700/attachment.htm>