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

Dear Job, all,

I think all would agree that transparency is good.

A key difference between RPKI and most other PKIs is that in the RPKI all objects
are published in the open for all the see. As you mentioned your RPKI validator
may miss intermediate state changes if it retrieves objects using rsync, but the
RRDP protocol supports deltas, see [1].

I believe that transparency can most easily be achieved by ensuring that these
deltas are preserved, and that they cannot be modified.

Kind regards,

Tim


[1]: https://rrdp.ripe.net/notification.xml




> On 9 Sep 2021, at 18:25, Job Snijders via routing-wg <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/
>