[routing-wg] request for feedback: a RPKI Certificate Transparency project?

Hi Job, 

Thanks for bringing this up and I would be supportive for setting up the activity for keeping the CT logs.  

Topics that we should keep in mind on the scope for the NCC..  Are we asking the NCC to provide feeds to third parties .. ( aka . the NCC (or their infra) doesn't store it themselves ) 
Or are we also asking the NCC to setup a storage pool and start collecting the data .. And build some tools around that. 

These are 2 very different investments and both should be looked at imho. 

On the third parties, that could be one of the other RIR's .. if they would be doing a similar project. And store the data among each other. 

The goal for transparency imho is to make sure that the data is stored at a place where it can't be adjusted, or at a location where the admin doesn't have an incentive to fiddle around with it to cover up some boo-boo's .. 
If that was intentional .. or by the form of a hack. 

Will the cost of such an infrastructure be beneficial .. compaired to the cost .. ? 
It is hard to put things like this in perspective .. you don't know if it holds value to the community .. upto the point where we look at the data .. and find something horribly wrong .. what we wouldn't have found otherwise.. 
or if it will make our lives a lot easier in a case where the you know what hits the you know where .. and we don't have any logs to look into ..  

It is the same as with projects like RIS or Atlas .. until you look at the data when you need it .. you won't see the value, just the cost .. 
I've been using both in the past and it allowed me to confirm or deny certain claims that wasn't possible otherwise.. 

I rather have the CT logs just sitting idle for 10 years .. but once we need it .. it would be good to have something to look at. 
But I would like to see if we can get some kind of cost indication and what it would mean in size of project and FTE.. ( after implementation of the actual .. turning it on .. )  

Regards,
Erik Bais 


On 09/09/2021, 18:26, "routing-wg on behalf of Job Snijders via routing-wg" <routing-wg-bounces at ripe.net on behalf of routing-wg at ripe.net> wrote:

    Dear all,
    
    With summer turning to fall in the Northern Hemisphere, yet again a new
    schoolyear is ahead of us! :-) I hope you all are well.
    
    I'm writing the group to solicit feedback for me and others to consider
    during upcoming deliberations about activity plans, but even more so as
    an RPKI enthusiast who is curious to learn what others see as potential
    future evolutions of the RPKI technology stack.
    
    [ TL;DR - Ask to the routing community: is there interest to coordinate
      and support an industry-wide project to introduce the principles of
      "Certificate Transparency" to the RPKI? The project size could be
      substantial, but so are the upsides. ]
    
    Intro: global deployment & operation of the RPKI is a multi-decade project
    ==========================================================================
    
    Over the last 21 years this industry has collectively helped grow and
    nurture 'Secure BGP' [1] into the RPKI/BGP deployment as we know it
    today: the smallest and largest of networks in the Default-Free Zone
    core are anchoring their BGP routing decisions to a RPKI covering 31% of
    space, which in turn helps connect billions of End Users to the
    Internet.
    
    From my personal perspective [10], the RPKI has now reached some level
    of maturity. Perhaps now is the time for some of our community's focus
    to shift towards designing and implementing innovations on top of the
    current RPKI, without jeopardizing its current plateau of stability.
    
    What does trusting a Trust Anchor mean?
    =======================================
    
    Some people have (correctly!) pointed out that RPKI Trust Anchor (TA)
    operators technically can issue certificates related to any Internet
    Number Resource, a consequence of some people considering "all
    resources" [5] being subordinate a necessity for day-to-day TA
    operations. While I am aware of some minor concerns about the "all
    resources" framework (and I personally see room for improvement!), for
    me the big question is not "who do I trust?", but "what did they
    actually do after I started trusting them?".
    
    In this reality where RIRs can sign "everything" and I (as RP operator) can
    cryptographically verify that what I observed through periodic polling
    [6] was indeed signed by my locally configured Trust Anchor(s)... one
    thing seems to be missing! I don't know anything about what my RP didn't
    observe! :-) Perhaps some certificates were issued and very quickly
    revoked concerning subordinate Internet Number Resources of great
    importance to me? How would I know if I didn't see it myself?
    
    I don't expect to trust Trust Anchor operators to never make any
    mistakes, but I do wish to be in a position where I can assess past
    performance, and can compare third-party audit logs, to inform my future
    decisions! To me it seems important to increase our collective
    visibility into TA/CA takes & mistakes. ("Mistakes" meaning the issuance
    or revocation of certificates non-compliant with the policy outlined in
    RIPE-751).
    
    Most Internet Routing incidents are analyzed after-the-fact through the
    use of Route Views [8], RIPE RIS [9], or information viewplayers like
    BGPlay. Everyone being enabled to "scrub back in time" greatly enhances
    our group's ability to understand what transpired and how to prevent it
    going forward.
    
    What is the RPKI equivalent of BGPlay at a cryptographicly auditable
    level of detail? ... maybe Certificate Transparency? [7].
    
    Copying good ideas from other PKIs: Certificate Transparency
    ============================================================
    
    The RPKI is built on top of X.509 and CMS tech. Any developments in
    other X.509 special interest communities (such as WebPKI [2], aka "the
    https:// experts"), may be amazing ideas or methods worth copying into
    'our Internet Number Resource PKI' ecosystem. 
    
    One of the inventors [3] of public-key cryptography (a core concept in
    the RPKI), also came up with an idea known as "Merkle Trees" [4]. This
    concept can be used to construct inter-domain "append-only" logging
    facilities, which can be incredibly useful to help increase trust in a
    Trust Anchor in an "assumed trust" model. I'll try to explain why below!
    
    A key concept in Certificate Transparency is that a CA ('the signer')
    - ahead of time - shares with select third parties (so-called 'CT Logs')
    their commitment to sign a given digital object. After acknowledgement
    from the CT Log(s), the signer proceeds to sign and publish the RPKI
    object. The CT Logs use Merkle Trees to allow external auditors to
    'losslessly replay' all observations of certificate issuance from a
    given CT Log, and compare CT Logs with each other.
    
    Implementation of Certificate Transparency would provide this community
    with something analogous to the RIPE Database "Historical Queries". The
    major difference being all logged data comes with cryptographic
    assurances, and the data can be hosted and audited by both RIPE NCC and
    any third parties (anyone with Internet access!).
    
    RIPE NCC sending precertificate information to CT Logs?
    =======================================================
    
    Would the community mind if RIPE NCC proactively shares to-be-signed
    not-yet-public-but-soon-to-be-public information with third parties?
    
    Are there any third parties (could be ISPs like you and me, or RIRs [13]
    in other regions) who'd be willing to host and operate 24/7 available CT
    Logs working with software such as Trillian [12]?
    
    RIPE NCC as Certificate Transparency Log Operator for other RIRs?
    =================================================================
    
    RIPE NCC appears to have an impressive track record when it comes to
    bootstrapping and maintaining 'impossible' multi-year projects which
    improve "the commons". RIPE Atlas and RIPE RIS are projects only very
    few organizations would've been able to pull off. Both RIS and Atlas
    offer incredible value to both the RIPE community and the global
    community. In my eyes an RPKI Certificate Transparency initiative would
    align well with existing projects.
    
    Bootstrapping and maintaining RPKI CT Logs (the open source software
    design, subsequent IETF draft contributions, ongoing data processing and
    archiving) will require significant investment. However, I do believe
    there is an opportunity for RIPE NCC to serve the global Internet
    community by offering RPKI CT Log services to any TA or CA in the RPKI.
    
    Final thoughts
    ==============
    
    Certificate Transparency is an open framework that can help detect
    Signed Object trust threats, and brings increased oversight and openness
    to the RPKI ecosystem.
    
    Does the community see value in applying Certificate Transparency to the
    RPKI? What are your thoughts?
    
    Kind regards,
    
    Job
    
    [1]: https://ieeexplore.ieee.org/document/839934
    [2]: https://cabforum.org/
    [3]: https://en.wikipedia.org/wiki/Ralph_Merkle
    [4]: https://iq.opengenus.org/merkle-tree/
    [5]: https://datatracker.ietf.org/doc/html/draft-rir-rpki-allres-ta-app-statement
    [6]: http://www.rpkiviews.org/
    [7]: https://en.wikipedia.org/wiki/Certificate_Transparency
    [8]: http://routeviews.org/
    [9]: https://www.ripe.net/analyse/internet-measurements/routing-information-service-ris
    [10]: https://console.rpki-client.org/
    [11]: https://datatracker.ietf.org/doc/html/draft-ietf-trans-rfc6962-bis
    [12]: https://github.com/google/trillian
    [13]: https://www.arin.net/participate/community/acsp/suggestions/2021/2021-3/