One of the things Cloudflare describes is their CT log for the RPKI, Cirrus.
I can see why they did that, CT was a huge benefit for the Web PKI and many of the things we did to the Web PKI are things they'd like to see happen for RPKI - more people using it, better technical compliance by issuers, more eyeballs on the problems, CT probably helped with some of those.
But the Web PKI is a vast sprawling mess. CT was necessary _because_ of that mess, we know we can't stop it being a mess, so we needed technology that could cope. The RPKI is neither vast, nor sprawling, nor especially messy.
A big part of what drove improvements to the Web PKI was the effort by people with the power to get things changed. In the case of the Web PKI that's Mozilla, the Mozilla community (since Mozilla is a charity) and to a lesser extent the big commercial vendors, Microsoft, Apple, Google, Oracle. CT was a _tool_ these players could use as part of that work, but on its own it didn't get the job done.
But in RPKI there isn't really an equivalent. Companies like Cloudflare don't have anywhere near the clout to get this done. Even the backbone providers don't. And if we're to expect the RIRs to fix it, they don't need any help getting insight on issuers when they themselves are the issuers.
So, Cirrus isn't hurting anything, but I hope its creators had very limited expectations and expended minimal resources getting it up, because I doubt it's a major part of the solution to our problems either.
Is Cirrus mentioned in the blog post? I can't find it.
Right now, the way key compromise might be detected in RPKI is that a human network operator notices a signed object which is obviously suspicious and posts it on a mailing list. This is the same way that CA compromise was detected in the Web PKI before CT.
CT was useful well before Chrome used their weight to make it required for all new certificates because it was no particular burden on a few people (CA or not) who saw a lot of certificates to add them to CT. This gave the people who might not see a lot of certificates but want to find something weird a corpus to dig into.
Same idea applies to RPKI. But yes, setting up Cirrus took very little of my time.
1. I don't know of any issuer key compromises detected with CT. Such compromises are rare. DigiNotar is an obvious example, but can you think of any recent ones? Mostly CA incompetence is more subtle that "Oops we left the root keys on a train" and I'd hope the same is true for RIRs.
2. Technically CT is still not required. You can choose to obtain certificates which aren't logged from a CA that will issue them without logging. Neither Google nor Mozilla require you to log all certificates as a condition of their root programmes and both recently confirmed they do not intend to make that a requirement. Chrome will mark your cert as untrustworthy if it hasn't got an SCT and so it would always make sense to log certificates for a site Chrome users will access on the public Web, but not every TLS certificate is for a web site accessed with Chrome.
[ Also, Google actually makes use of the fact that certs can exist without being logged for some systems. Suppose they're about to launch amazing.example.com, but even the Amazing name would give away what it is. They can order the cert for amazing.example.com with no logging and stockpile it, and when the brass signs off on actually announcing Amazing they log this cert, almost instantly getting back SCTs, and configure a suitably modern web server to send the SCTs separately alongside the certificate. Where ordering a certificate internally might take hours or days, these final steps can be done in a few minutes and need no special permission. Any subscriber whose CA is willing to issue unlogged certificates can do this, but just make sure you have all the steps correct or you'll look really dumb, even Google got this wrong at least once since they began doing it ]
> I don't know of any issuer key compromises detected with CT. Such compromises are rare. DigiNotar is an obvious example, but can you think of any recent ones?
We've known about BGP hijacking attacks for 20 years and they only seem to be an issue now. In my day, kids would inject routes using spoofed RIP UDP packets from dial-up pools that would get redistributed into the global routing tables. I haven't 'sho ip' anything'ed in more than a decade, but it appears that 20 years later, you can still just compromise a router and announce whatever you want.
The threat model has changed, where then you could send some spam or harvest passwords for shell logins, today we have things like millions of dollars in piles of electronic cash sitting around relatively unprotected and untraceable, a hyper-polarized political environment where people believe they need strong anonymity protections to participate, and the ability to scale the C&C functions for botnets to where they now resemble private darknets.
All the real action seems to be happening in software defined networks in the cloud these days, but it all still depends on this legacy internet infrastructure.
I'm glad CloudFlare is doing this. Someone needed to take the initiative. It was one of those things where it was everybody's problem, which meant it was nobody's problem.
It turns out that most upstream providers have route filters, so you can't just announce whatever you want...
I do remember those days in the 90's, though. I worked at a small ISP, and a coworker blackholed a few spammers by just announcing their route and sending all traffic to Null0. This was back in the Cisco 4000 days, when a full routing table could fit in 32 megs. If I recall, our upstream was Sprintlink and they didn't do any filtering at the time.
The reason that the existing BGP setup is so barebones (that is, lacking in any meaningful security beyond simple route filtering) is because introducing more complexity is failure-prone... and not just from error or misconfiguration either. Outages, propagation, malice... there are a lot of ways in which this could break and make things less reliable than they are now.
My main concern is censorship. This would allow the RiRs, via revocations or failures-to-renew a cert for a given address space, to knock a network off of the internet without further human intervention on the part of the peers to which the censored party is directly connected.
Give them this tooling, and their national governments or militaries will demand its use when they are sufficiently angered, agitated, or threatened.
Can you really imagine the US military or DoJ not demanding RiRs use such a tool against e.g. an AS hosting Wikileaks or Snowden files or The Shadow Brokers?
I’m not sure that the current insecure BGP model is broken enough to warrant introducing this new cryptographic fail-closed failure mode.
The five Regional Internet Registries (ARIN, APNIC, LACNIC, AFRINIC and RIPE NCC), who are responsible for registering IP addresses and AS Numbers in their respective regions. They have the authoritative information on who is the legitimate holder of a resource, so it fits the model.
So this means that the national governments/militaries of the countries in which those entities are located would then have the practical ability to force a revocation that causes someone’s routes to become invalid? This seems like a giant legal SPoF for censorship.
ISTM if these entities were a threat of that sort, they would have already caused problems? Besides ARIN, none of them are really under the control of any one nation, are they?
Nothing the RiRs do right now immediately affects routing on the internet. There is a patchwork of systems, some automatic, some manual, that eventually converge their authority onto the routers that actually do the routing.
This proposal turns that system (which mostly works well) into a a system that has somewhat centralized algorithmic control. If routers enforce valid signed records for routing, suddenly the RiRs have an instant, practical power they did not have before.
First of all, BGP routing doesn't work that well at all. There's thousands of BGP hijacks per year [1]; the ones you read about in the news are just the most noteworthy. There are tons of smaller and larger outages because of fat fingering and misconfigurations RPKI can help protect against.
Secondly, the RIRs also have the ability to revoke IP address allocations and AS numbers, as well as whois database objects and IRR route objects. An RPKI resource certificate is just a different representation of an RIR resource registration, it's not going to make the difference you claim.
Then, it would also be fairly stupid of a government to abuse a system that is designed to protect the internet from hijacking of critical infrastructure for censorship purposes. The RIRs have done extensive outreach to make this clear to their respective governments. Still, as soon as a government would try a stunt like this, the networking community would simply walk away from this technology in an instant.
Most importantly though, a revoked or expired certificate would result in a BGP announcement with the status 'unknown', as if the operator doesn't participate in the system and the route were never signed in the first place. The route would never become invalid, and thus unreachable.
Revoking an IP or AS allocation doesn’t actually immediately stop anyone from using it in practice, though, until their peers stop treating them as valid (which is not instantaneous upon RiR fiat).
The networking community would not walk away from abuse in a literal instant, though. It would take days at a minimum, while censorship would occur instantly. It may be a single use weapon but it is still a weapon.
I am not sure that BGP is broken enough to warrant the signing of allocations (or, more specifically, to fail-closed on unsigned/expired allocations).
I recently went around to the most popular websites with ssh-keygen guides, trying to get them to update their documentation to use the -o option. (Hint: your private key password may be vulnerable to brute-force)
The only people that ignored or refused to update their docs were corporations and large institutions. I believe now that these kind of organizations simply will never do what they should be doing on their own accord, until someone/something forces them to.
Regular-old corporate laziness aside, the legal issues behind who manages the CAs will probably need to get resolved before anyone in RIPE even begins to implement RPKI.
Sadly, no, nothing out there is comprehensive (Arch Linux's SSH keys article is not bad, but still pretty limited). There's always the manual: https://man.openbsd.org/ssh-keygen
One of the things Cloudflare describes is their CT log for the RPKI, Cirrus.
I can see why they did that, CT was a huge benefit for the Web PKI and many of the things we did to the Web PKI are things they'd like to see happen for RPKI - more people using it, better technical compliance by issuers, more eyeballs on the problems, CT probably helped with some of those.
But the Web PKI is a vast sprawling mess. CT was necessary _because_ of that mess, we know we can't stop it being a mess, so we needed technology that could cope. The RPKI is neither vast, nor sprawling, nor especially messy.
A big part of what drove improvements to the Web PKI was the effort by people with the power to get things changed. In the case of the Web PKI that's Mozilla, the Mozilla community (since Mozilla is a charity) and to a lesser extent the big commercial vendors, Microsoft, Apple, Google, Oracle. CT was a _tool_ these players could use as part of that work, but on its own it didn't get the job done.
But in RPKI there isn't really an equivalent. Companies like Cloudflare don't have anywhere near the clout to get this done. Even the backbone providers don't. And if we're to expect the RIRs to fix it, they don't need any help getting insight on issuers when they themselves are the issuers.
So, Cirrus isn't hurting anything, but I hope its creators had very limited expectations and expended minimal resources getting it up, because I doubt it's a major part of the solution to our problems either.
Is Cirrus mentioned in the blog post? I can't find it.
Right now, the way key compromise might be detected in RPKI is that a human network operator notices a signed object which is obviously suspicious and posts it on a mailing list. This is the same way that CA compromise was detected in the Web PKI before CT.
CT was useful well before Chrome used their weight to make it required for all new certificates because it was no particular burden on a few people (CA or not) who saw a lot of certificates to add them to CT. This gave the people who might not see a lot of certificates but want to find something weird a corpus to dig into.
Same idea applies to RPKI. But yes, setting up Cirrus took very little of my time.
You're correct, it's mentioned in the next/ accompanying post https://blog.cloudflare.com/rpki-details/
Some small corrections if I may
1. I don't know of any issuer key compromises detected with CT. Such compromises are rare. DigiNotar is an obvious example, but can you think of any recent ones? Mostly CA incompetence is more subtle that "Oops we left the root keys on a train" and I'd hope the same is true for RIRs.
2. Technically CT is still not required. You can choose to obtain certificates which aren't logged from a CA that will issue them without logging. Neither Google nor Mozilla require you to log all certificates as a condition of their root programmes and both recently confirmed they do not intend to make that a requirement. Chrome will mark your cert as untrustworthy if it hasn't got an SCT and so it would always make sense to log certificates for a site Chrome users will access on the public Web, but not every TLS certificate is for a web site accessed with Chrome.
[ Also, Google actually makes use of the fact that certs can exist without being logged for some systems. Suppose they're about to launch amazing.example.com, but even the Amazing name would give away what it is. They can order the cert for amazing.example.com with no logging and stockpile it, and when the brass signs off on actually announcing Amazing they log this cert, almost instantly getting back SCTs, and configure a suitably modern web server to send the SCTs separately alongside the certificate. Where ordering a certificate internally might take hours or days, these final steps can be done in a few minutes and need no special permission. Any subscriber whose CA is willing to issue unlogged certificates can do this, but just make sure you have all the steps correct or you'll look really dumb, even Google got this wrong at least once since they began doing it ]
[edited to fix typo that reversed my meaning]
> I don't know of any issuer key compromises detected with CT. Such compromises are rare. DigiNotar is an obvious example, but can you think of any recent ones?
Not key compromise, but general mis-issuance:
Facebook detected overreach by a vendor with CT: https://www.facebook.com/notes/protect-the-graph/early-impac...
AGL detected certs that were malformed in various ways: https://www.imperialviolet.org/2013/08/01/ctpilot.html
> Technically CT is still not required.
It produces an interstitial, see: https://invalid-expected-sct.badssl.com/
We've known about BGP hijacking attacks for 20 years and they only seem to be an issue now. In my day, kids would inject routes using spoofed RIP UDP packets from dial-up pools that would get redistributed into the global routing tables. I haven't 'sho ip' anything'ed in more than a decade, but it appears that 20 years later, you can still just compromise a router and announce whatever you want.
The threat model has changed, where then you could send some spam or harvest passwords for shell logins, today we have things like millions of dollars in piles of electronic cash sitting around relatively unprotected and untraceable, a hyper-polarized political environment where people believe they need strong anonymity protections to participate, and the ability to scale the C&C functions for botnets to where they now resemble private darknets.
All the real action seems to be happening in software defined networks in the cloud these days, but it all still depends on this legacy internet infrastructure.
I'm glad CloudFlare is doing this. Someone needed to take the initiative. It was one of those things where it was everybody's problem, which meant it was nobody's problem.
It turns out that most upstream providers have route filters, so you can't just announce whatever you want...
I do remember those days in the 90's, though. I worked at a small ISP, and a coworker blackholed a few spammers by just announcing their route and sending all traffic to Null0. This was back in the Cisco 4000 days, when a full routing table could fit in 32 megs. If I recall, our upstream was Sprintlink and they didn't do any filtering at the time.
The reason that the existing BGP setup is so barebones (that is, lacking in any meaningful security beyond simple route filtering) is because introducing more complexity is failure-prone... and not just from error or misconfiguration either. Outages, propagation, malice... there are a lot of ways in which this could break and make things less reliable than they are now.
My main concern is censorship. This would allow the RiRs, via revocations or failures-to-renew a cert for a given address space, to knock a network off of the internet without further human intervention on the part of the peers to which the censored party is directly connected.
Give them this tooling, and their national governments or militaries will demand its use when they are sufficiently angered, agitated, or threatened.
Can you really imagine the US military or DoJ not demanding RiRs use such a tool against e.g. an AS hosting Wikileaks or Snowden files or The Shadow Brokers?
I’m not sure that the current insecure BGP model is broken enough to warrant introducing this new cryptographic fail-closed failure mode.
So who gets the signing authority in this proposed/upcoming RPKI?
The five Regional Internet Registries (ARIN, APNIC, LACNIC, AFRINIC and RIPE NCC), who are responsible for registering IP addresses and AS Numbers in their respective regions. They have the authoritative information on who is the legitimate holder of a resource, so it fits the model.
So this means that the national governments/militaries of the countries in which those entities are located would then have the practical ability to force a revocation that causes someone’s routes to become invalid? This seems like a giant legal SPoF for censorship.
ISTM if these entities were a threat of that sort, they would have already caused problems? Besides ARIN, none of them are really under the control of any one nation, are they?
Nothing the RiRs do right now immediately affects routing on the internet. There is a patchwork of systems, some automatic, some manual, that eventually converge their authority onto the routers that actually do the routing.
This proposal turns that system (which mostly works well) into a a system that has somewhat centralized algorithmic control. If routers enforce valid signed records for routing, suddenly the RiRs have an instant, practical power they did not have before.
First of all, BGP routing doesn't work that well at all. There's thousands of BGP hijacks per year [1]; the ones you read about in the news are just the most noteworthy. There are tons of smaller and larger outages because of fat fingering and misconfigurations RPKI can help protect against.
Secondly, the RIRs also have the ability to revoke IP address allocations and AS numbers, as well as whois database objects and IRR route objects. An RPKI resource certificate is just a different representation of an RIR resource registration, it's not going to make the difference you claim.
Then, it would also be fairly stupid of a government to abuse a system that is designed to protect the internet from hijacking of critical infrastructure for censorship purposes. The RIRs have done extensive outreach to make this clear to their respective governments. Still, as soon as a government would try a stunt like this, the networking community would simply walk away from this technology in an instant.
Most importantly though, a revoked or expired certificate would result in a BGP announcement with the status 'unknown', as if the operator doesn't participate in the system and the route were never signed in the first place. The route would never become invalid, and thus unreachable.
[1] https://www.internetsociety.org/blog/2018/01/14000-incidents...
Revoking an IP or AS allocation doesn’t actually immediately stop anyone from using it in practice, though, until their peers stop treating them as valid (which is not instantaneous upon RiR fiat).
The networking community would not walk away from abuse in a literal instant, though. It would take days at a minimum, while censorship would occur instantly. It may be a single use weapon but it is still a weapon.
I am not sure that BGP is broken enough to warrant the signing of allocations (or, more specifically, to fail-closed on unsigned/expired allocations).
I'd argue that BGP works really well given how large the Internet has grown over the past 25 years, and how little BGP has changed in that time.
Nothing will change until there is a significant attack on BGP resulting in widespread network outages.
Like these events?
https://arstechnica.com/information-technology/2010/11/how-c...
https://www.theregister.co.uk/2017/12/13/suspicious_bgp_even...
Never assume malice when incompetence suffices.
That happens rather frequently. I think RPKI will be adopted but it will be a slow process like IPv6 adoption.
I recently went around to the most popular websites with ssh-keygen guides, trying to get them to update their documentation to use the -o option. (Hint: your private key password may be vulnerable to brute-force)
The only people that ignored or refused to update their docs were corporations and large institutions. I believe now that these kind of organizations simply will never do what they should be doing on their own accord, until someone/something forces them to.
Regular-old corporate laziness aside, the legal issues behind who manages the CAs will probably need to get resolved before anyone in RIPE even begins to implement RPKI.
Can you recommend a "canonical" ssh-keygen guide?
Sadly, no, nothing out there is comprehensive (Arch Linux's SSH keys article is not bad, but still pretty limited). There's always the manual: https://man.openbsd.org/ssh-keygen