Re: ARIN RPKI TAL deployment issues

[Claudio Jeker <cjeker () diehard n-r-g com>]

On Wed, Sep 26, 2018 at 03:29:33AM -0400, Jared Mauch wrote:
> > On Sep 26, 2018, at 3:13 AM, John Curran <jcurran () arin net> wrote:
> >
> > On 26 Sep 2018, at 2:09 AM, Christopher Morrow <morrowc.lists () gmail com> wrote:
> > > (I'm going to regret posting this later, but...)
> > >
> > > On Tue, Sep 25, 2018 at 10:57 PM John Curran <jcurran () arin net> wrote:
> > >
> > > The significant difference for ARIN is that we operate under a different legal regime, and as a matter of US law, 
> > > it appears that we cannot rely only upon terms and conditions published in our website as evidence of informed 
> > > agreement; i.e. within the US legal framework, we need a specific act of acceptance in order to have a binding 
> > > agreement.  
> > >
> > > how is arin's problem here different from that which 'lets encrypt' is facing with their Cert things?
> >
> > Chris - 
> >
> > The “Let’s encrypt” subscriber agreement (current version 1.2, 15 Nov 2018) includes "indemnify and hold harmless” 
> > clause, and parties affirmatively agree to those terms by requesting that ISRG issue a "Let’s Encrypt” Certificate 
> > to you.
> >
> > (I don’t know whether that process is particularly more or less onerous technically than the effort to download the 
> > ARIN TAL.) 
>
> The process for lets encrypt is fairly straightforward, it collects some minimal information (eg: e-mail address, 
> domain name) and then does all the voodoo necessary.  If ARIN were to make this request of the developers of RPKI 
> software, it would seem reasonable to have that passed to ARIN via some API saying “bob () example com” typed “Agree” 
> to the ARIN TAL as part of the initial installation of the software.
>
> For me, this is about the friction involved in making it work and while the click-through page may not seem like a 
> barrier, there are active measurements that demonstrate it is.  It may take time to communicate to the existing set 
> of operators running RPKI validators they are missing the ARIN TAL, but I would like to ensure that new deployments 
> don’t make this same mistake.
>
> I think this thread/communication is part of that.  “Don’t forget about the extra step for ARIN”.  It’s also “ARIN, 
> please help make it easier to use your service”.
>
> With Google Maps, etc.. I may have to create an API key, it comes in multi-lingual systems in non-roman alphabet 
> support, etc.  Being part of this global ecosystem and running an RIR comes with some extra effort compared to 
> running a corner mom & pop shop.  Our actions and decisions have global consequences to the safety and security of 
> how your and my traffic is routed.
>
> Please work with the developers for a suitable method to include the ARIN TAL by default.  Come up with the 
> click-accept legalese necessary.
>
> Since you asked, here’s what they did with the CertBot that’s commonly used by Lets Encrypt:
>
>
>     (The first time you run the command, it will make an account, and ask for an email and agreement to the Let’s 
> Encrypt Subscriber Agreement; you can automate those with --email and --agree-tos)
>
>     If you want to use a webserver that doesn’t have full plugin support yet, you can still use “standalone” or 
> “webroot” plugins to obtain a certificate:
>
>     ./certbot-auto certonly --standalone --email admin () example com -d example.com -d www.example.com -d 
> other.example.net
>
> If you/ARIN could work closer with the developers of RPKI software to help make this happen that would be great.  If 
> you need introductions, I’m happy to help make them.

This is the wrong side of the system. If you want to compare the
ARIN TAL to anything related to letsencrypt then it is the TLS root
certificates which are shipped by all OS and browsers. This discussion
is not about the process to get a cerificate (or ROA entry signed) this is
about shipping the trust anchor, which makes the system actually work.
As an opensource developer what I need is to be able to ship the public
key together with my software so that the verification works out of the
box. Without the public key (TAL) none of the ARIN ROA entries can be
validated. I do not understand why a public key is under a click-accept
license. If fear of indemnification is an issue then how is it possible
that so many US public keys are shipped with the TLS/SSL root certificates
without any issue?

ARIN can still use the same license for customers wanting to add entries
to the ARIN RPKI database. It is just about the fact that a 3rd party that
has nothing todo with ARIN needs to accept their licence to be able to
verify that the ARIN signed ROA entry is acctually valid. No other validation
system (DNSSEC, TLS/SSL) is doing that. It is actually in the interest of
ARIN and all ARIN members that the TAL is as widely distributed as
possible since only then adding a ROA actually gives you the intended
benefit.

-- 
:wq Claudio