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

Hi Job,

> On 20210909, at 18:25, Job Snijders via routing-wg <routing-wg at 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