ARIN RPKI TAL deployment issues

Wed Sep 26 08:02:16 UTC 2018

On Wed, Sep 26, 2018 at 03:29:33AM -0400, Jared Mauch wrote:
> 
> 
> > On Sep 26, 2018, at 3:13 AM, John Curran <jcurran at arin.net> wrote:
> > 
> > On 26 Sep 2018, at 2:09 AM, Christopher Morrow <morrowc.lists at gmail.com> wrote:
> >> 
> >> (I'm going to regret posting this later, but...)
> >> 
> >> On Tue, Sep 25, 2018 at 10:57 PM John Curran <jcurran at 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 at 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 at 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