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

[John Curran]

On 1 Feb 2017, at 4:01 AM, Job Snijders <job at ntt.net<mailto:job at ntt.net>> wrote:
I am certain that an appropriate (and equally short) wget command
could suffice technically for installing ARIN’s TAL, but including
such in a script (or including the TAL directly in the source code
repository) would deprive parties of the ability to fully consider and
accept the responsibilities involved.

Correct. Thank you for this summary. Your summary narrows it down to
exactly the point of friction.

Questions that come to mind: are the responsibilities as outlined by the
RPA proportional to the goals the RPA is intended to achieve? Should any
responsibilities be associated with the distribution of cryptographic
public keys? To me DNSSEC seems an apt comparison.

Job -

The typical relying parties “usage” of certificates in DNSSEC is heavily proscribed by
both protocol and implementation, and occurs with only nominal configuration choices on
behalf of the relying party.  Both the maturity of DNSSEC and deployment model greatly
minimize the potential for misconfiguration on behalf of a relying party, with the result being
that misconfiguration by zone administrators is a much more common occurrence and one
whose impact is limited to but their own domain (reference RFC 7646 for more detail on
same and thus the desire for locally administered negative trust anchors to address
such circumstances...)  Even when a DNSSEC validation error occurs, there remains the
potential for self-help on behalf of end users (via the option to switch to a non-validating
resolver.)

Contrast this to RPKI, wherein the introduction of origin validation into an ISP’s routing
architecture has many operational considerations, and inherently includes the potential to
readily impact the ISP's primary business under anything less than carefully planned and
executed BGP origin validation deployment efforts.   While I’m am certain that everyone
deploying RKPI has BCP 185 memorized, the scope of any such impacts (and lack of viable
workarounds by the impacted customers) inherently means the potential for business impact
is greater than exists with deployment of DNSEC validation by ISPs – i.e. while I do believe
that your comparison to DNSSEC is directionally correct, it fails overall due to the very real
and significant difference in the magnitude of potential business impact to the relying party.

/John

John Curran
President and CEO
ARIN





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20170201/537648b5/attachment.htm>