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" <[email protected] on behalf of [email protected]> 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/
