request for feedback: a RPKI Certificate Transparency project?
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-servi... [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/
Job Snijders via routing-wg wrote on 09/09/2021 17:25:
Does the community see value in applying Certificate Transparency to the RPKI? What are your thoughts?
there's certainly value in the ability to verify. What's not clear is whether there is enough value in the output to justify the time and resources in design, implementation and ongoing operation. Do you have any thoughts on how much resourcing this would require? Nick
Hi Job,
On 20210909, at 18:25, Job Snijders via routing-wg <routing-wg@ripe.net> wrote: [..] Does the community see value in applying Certificate Transparency to the RPKI? What are your thoughts?
TLDR: - Can be useful in case of incidents - there are a few useful tools out there, but no history yet (afaik) - Might need also a similar standard BGP-update CT... - fewer TAs than CAs, less chance of mis-issuance between them (hierarchical, unlike CA where CAA restriction is honor code) Job, thanks, as with many other things, to bringing this up! CT is watching the watchers. It requires also that something actually acts upon alerts, but at least you get some stats and history out of it. CT for RPKI sounds logical as it could expose events like: - Trust Anchor compromise (in case the original owner did not request it) - newly signed routes - mis-signed routes (but that would imply TA compromise) - TA signing a route for a route it should not. Unlike the CA system where there where hundreds of CAs (though >70% of certs are now Let's Encrypt issued, see also the great dashboards on https://ct.cloudflare.com), RPKI only has a few actual sources (RIRs primarily). It is also afaik rather hard unless there is a compromise, to issue something not signed by the RIRs, and that would effectively mean a RIR compromise. Also the CAA records that are recent and optional are based on the honor code; for RPKI, the RIR effectively already determines if one can issue the resource or not. So, while I expect it to be useful, especially for historical reasons, browsing and discovery (OSINT: eg lots use crt.sh to find hosts in a destination domain) or for finding falsely issued certs (somebody running acme.sh unmanaged on a host); those models are a lot less expected in the RPKI case due the centralisation and strict controls already in place. The system would show them though, which is a good thing and we would have a log of the event, which is another good thing. There are also already existing systems like: IRR Explorer v2 (https://irrexplorer.nlnog.net or see slides/video by Sasha explaining the new system at https://nlnog.net/nlnog-day-2021/) and https://console.rpki-client.org [very many thanks to Job btw for both ;) ] I think that one would have to effectively have CT for BGP too, which would be harder due to AS Paths. Having at least dumps of BGP updates in a specific format, and being able to pull and analyze them, and mixing that with the info from the RPKI, could be very interesting. What makes CT very useful is the multiple vantage points. Though, due to the size of systems, how many vantages will be expected. For the CA system, they are at ~145897 certs/hr with 230512 certs/hr expiring -- that is about 100 certs per second. [numbers from Merkle Town, see ct.cloudflare.com], which seems like a small number, till you want to start from the beginning, takes ages to catch up or go through the backlog to find just certs matching your domains... :) ] Fortunately RPKI will likely be a lot smaller, thus likely, individuals (or at least LIR level) could easily run such a CT log. BGP updates would be a different story though... A "Routing Town" site would be a cool thing to have.... ;) Greets, Jeroen
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@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-servi... [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/
On Fri, Sep 10, 2021 at 11:39:39AM +0200, Tim Bruijnzeels wrote:
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.
Small nitpick: all objects are SUPPOSED to be published, in the open, for all to see. However it is important to keep in mind we cannot assume all objects were published in a way for all to 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.
RRDP is an unauthenticated and unsigned protocol. It is possible for a Publication Point to present different RRDP deltas to one RP compared to what they present to another RP. Archiving RRDP deltas is interesting, but IMHO happens too late in the pipeline for TA/CA audit purposes. RRDP is not a replacement for Certificate Transparency, both technologies solve different problems. Kind regards, Job
On 10 Sep 2021, at 11:57, Job Snijders <job@fastly.com> wrote:
On Fri, Sep 10, 2021 at 11:39:39AM +0200, Tim Bruijnzeels wrote:
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.
Small nitpick: all objects are SUPPOSED to be published, in the open, for all to see. However it is important to keep in mind we cannot assume all objects were published in a way for all to 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.
RRDP is an unauthenticated and unsigned protocol. It is possible for a Publication Point to present different RRDP deltas to one RP compared to what they present to another RP. Archiving RRDP deltas is interesting, but IMHO happens too late in the pipeline for TA/CA audit purposes.
RRDP is not a replacement for Certificate Transparency, both technologies solve different problems.
I did not say that it was. I just suggested that *in the context of RPKI* RRDP can be used as a basis to keep track of all historic public changes. I think we can discuss, preferably in the IETF as well, how multiple parties can observe changes in RRDP repositories and report them to an append only historic record. A useful concept also used in CT. Paranoid (as they should be) RPKI validators would then be able to verify that the state that they see (notification/snaphot/deltas) matches what others have seen. The biggest advantage to an approach like this could also be applied on top of the existing infrastructure without requiring substantial changes in the stack. If you do not trust that the Publication Server (which serves RRDP) accurately reflects what the RPKI CAs asked to be published then you indeed have a different problem. CT logs could be one way to approach this, but I am not convinced yet that this is the only way or the best way. Also note that in case of RIPE NCC the CAs and Publication Server are controlled by the same organisation. Kind regards, Tim
Kind regards,
Job
Hi Tim, On 09/10, Tim Bruijnzeels wrote:
On 10 Sep 2021, at 11:57, Job Snijders <job@fastly.com> wrote:
On Fri, Sep 10, 2021 at 11:39:39AM +0200, Tim Bruijnzeels wrote:
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.
Small nitpick: all objects are SUPPOSED to be published, in the open, for all to see. However it is important to keep in mind we cannot assume all objects were published in a way for all to 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.
RRDP is an unauthenticated and unsigned protocol. It is possible for a Publication Point to present different RRDP deltas to one RP compared to what they present to another RP. Archiving RRDP deltas is interesting, but IMHO happens too late in the pipeline for TA/CA audit purposes.
RRDP is not a replacement for Certificate Transparency, both technologies solve different problems.
I did not say that it was.
I just suggested that *in the context of RPKI* RRDP can be used as a basis to keep track of all historic public changes.
Archiving the RRDP deltas can certainly provide information as to what was observed at the publication points, but the security of the RPKI system lives at the object-signing layer, and so an audit log needs to capture activity at that layer: issuance actions by the CA. Comparing a CT log to RRDP delta archive could certainly be useful in many cases, but that's exactly because they say things about different parts of the infrastructure. Cheers, Ben
Hi Ben,
On 10 Sep 2021, at 13:11, Ben Maddison <benm@workonline.africa> wrote:
Hi Tim,
On 09/10, Tim Bruijnzeels wrote:
On 10 Sep 2021, at 11:57, Job Snijders <job@fastly.com> wrote:
On Fri, Sep 10, 2021 at 11:39:39AM +0200, Tim Bruijnzeels wrote:
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.
Small nitpick: all objects are SUPPOSED to be published, in the open, for all to see. However it is important to keep in mind we cannot assume all objects were published in a way for all to 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.
RRDP is an unauthenticated and unsigned protocol. It is possible for a Publication Point to present different RRDP deltas to one RP compared to what they present to another RP. Archiving RRDP deltas is interesting, but IMHO happens too late in the pipeline for TA/CA audit purposes.
RRDP is not a replacement for Certificate Transparency, both technologies solve different problems.
I did not say that it was.
I just suggested that *in the context of RPKI* RRDP can be used as a basis to keep track of all historic public changes.
Archiving the RRDP deltas can certainly provide information as to what was observed at the publication points, but the security of the RPKI system lives at the object-signing layer, and so an audit log needs to capture activity at that layer: issuance actions by the CA.
As I said:
If you do not trust that the Publication Server (which serves RRDP) accurately reflects what the RPKI CAs asked to be published then you indeed have a different problem. CT logs could be one way to approach this, but I am not convinced yet that this is the only way or the best way.
To make myself more clear, and then I will leave it to others speak.. I am not a priori opposed to CT as a solution. But this should start with a problem statement which is discussed in the IETF. The context of the RPKI standards matter and a lot of the contributors to those standards are not active here. There may be more than one way to solve the issues (which are still to be defined more clearly). If the outcome then is that there is a problem and CT is the solution, then I would be more than happy to support it. As it stands I think that asking the RIPE NCC to make a big investment without further analysis is questionable. It is also not sufficiently clear to me how and why this problem is more urgent than other investments in RPKI, e.g. providing a Publication Server service for members, and investing in support for ASPA. I hope it's clear to all that this is intended as constructive feedback to Job's question:
Does the community see value in applying Certificate Transparency to the RPKI? What are your thoughts?
Kind regards, Tim
Comparing a CT log to RRDP delta archive could certainly be useful in many cases, but that's exactly because they say things about different parts of the infrastructure.
Cheers,
Ben
Hi Tim,
But this should start with a problem statement which is discussed in the IETF. The context of the RPKI standards matter and a lot of the contributors to those standards are not active here.
It is not uncommon for initiatives to start in a special interest group outside the IETF, and then later on be presented to the appropriate IETF working group. For example the origins of the development of BGP Large Communities can be traced back to a NetNod meeting [1], later on the design was influenced based on feedback received at Routing WG @ RIPE 72, and then finally the specification was published as RFC via the IETF IDR WG. This message [2] is intended to start a conversation in the RIPE community specifically about the topic of Certificate Transparency and RPKI, because CT appears to have critically improved the WebPKI.
As it stands I think that asking the RIPE NCC to make a big investment without further analysis is questionable.
I agree, more study is needed before committing to big investments. Gauging community interest is part of the exploratory phase of the process.
It is also not sufficiently clear to me how and why this problem is more urgent than other investments in RPKI,
I don't recall anyone suggesting this is "more urgent than other investments"?
e.g. providing a Publication Server service for members, and investing in support for ASPA.
RIPE NCC maintains a list of plans here [4]. Neither Publication Server service nor ASPA are listed as of yet. Specific to about ASPA: as per last IETF 111 SIDROPS meeting [3], I think ASPA is pending the development of a testbed between various vendors coordinated through that IETF working group. It'll depend on market forces at what pace ASPA moves along. And do keep in mind that deployment of ASPA would mean we (network operators) collectively even more increase our dependency on the RPKI, which in my opinion strengthens the case to talk about additional oversight and auditability of Trust Anchors ... perhaps through Certificate Transparency! Kind regards, Job [1]: http://largebgpcommunities.net/2016/where-did-large-communities-start/ [2]: https://www.ripe.net/ripe/mail/archives/routing-wg/2021-September/004397.htm... [3]: https://www.youtube.com/watch?v=DtnFulym8CQ [4]: https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/rpki-plann...
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@ripe.net on behalf of routing-wg@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-servi... [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/
Hi all, Someone asked me off-list whether I had in mind to track all ROAs (they were concerned about scaling) or something else? A great question! I see as goal for Certificate Transparency in context of the RPKI is to track (in an immutable log) the delegations of authority as certified by the the RIRs and NIRs. The value of specifically tracking the resource delegations is twofold: A) Resource holders can monitor whether they (accidentally) lost any entitlements to any of their resources (aka, a "cryptographic service outage" from the perspective of the resource holder) B) Resource holders can monitor whether some other entity (accidentally) received entitlements to specific resources. (aka, the INR holder being at risk of a "cryptographic hijack") To have adequate and complete insight into the activities of the cryptopgrahic engine at RIPE NCC (and places like ARIN, LACNIC, NIC.MX, NIC.BR, etc), the Certificate Transparency principles only need to be applied to the "Production CA" (using RIPE-751 lingo), not to the subordinate products of Hosted CAs (such as ROAs), or Delegated CAs. Tracking the issuance of RPKI ".cer" files is in the order of "tens of thousands", with a growth curve which potentially maps to RIR membership growth/consolidation. These are low numbers. The RPKI numbers are a fraction of what "WebPKI" Logs and Auditors observe, which is good news, it means we can use small servers! :-) What to track and what not to track is up for discussion! Certificate Transparency for RPKI does not yet exist. Kind regards, Job
participants (6)
-
Ben Maddison -
Erik Bais -
Jeroen Massar -
Job Snijders -
Nick Hilliard -
Tim Bruijnzeels