Domain expiration is something that's more complicated than most people realize. As an example, I'm not sure if there's a definitive source stating that auto-renew grace is part of the ERRP. In my opinion it's not and the ERRP typically won't trigger for high value domains because they'll be sold or auctioned by the registrar instead.
As far as I know, the ERRP rules describe the policies for the deletion of expired domains, which isn't required, so working off the auto-renew grace status was a good choice here. Most people don't realize that expired domains aren't guaranteed to go through the ERRP lifecycle [1].
> You should be aware that during the auto-renew period, the domain name may be available to third parties for registration, depending on your registrar's terms of service. You may also run the risk of having your domain name auctioned to a third party by your registrar during this period (depending on your terms of service)
The process described here sounds like a pretty reasonable approach to a hard problem. It won't catch everything, but it's a good approach and it's nice to see some effort put into the issue.
This isn’t limited to just domains, though it’s good to consider. What happens when Google, Microsoft, or anyone else recycles unused accounts? Unfortunately for them, it seems like email addresses have been so tightly coupled with identity that it seems unreasonable that an address could be reused after any period of account inactivity.
I was angry when I realized my hotmail account I used from 2000 all the way through the 2010s got wiped by Microsoft. I was using gmail more, but still someone else got my old email and all the emails I used to receive along with it I'm sure.
I wish Microsoft had done this to my deleted Hotmail, instead some random person got my email, and potentially access to every website I ever registered to with said email...
Google's support page says they don't recycle usernames, ever so once an email is registered that's it, even after they delete the account. However, the by product of that is you won't be able to re-register that email. Once its gone, its gone forever.
FWIW I am unable to register a gmail for an account I deleted probably 8 years ago at this point. That said I don't know if there is anywhere where it explicitly outlines if it is or is not possible.
Oh funny. They started the recovery process then wanted me to add a phone number so they can send a recovery code. In spite of them first sending a recovery code to the email that I do control and me entering it.
I pressed 'try another way' and they told me they don't have enough information to prove the account is mine.
Fuck off Google basically. They could at least be honest and state that a phone number is required, instead of pretending that it's for verification.
Even if you provide a phone number, it will never send the required code or information and you will still be locked out of your account.
That is how I am locked out of a gmail account... eventhough I have the right username/password, and backup email, and typed in a phone number, Google won't let me back in.
This is exactly the kind of proactive security thinking we need more of. Supply chain attacks are getting more sophisticated, and preventing domain resurrection attacks is smart defensive strategy. Too many security incidents happen because someone thought "that'll never happen to us." PyPI is thinking ahead about attack vectors before they become widespread problems.
One of the places this worried me the most was Golang, where domains for repositories are used as a package source. Credit where credit's due, when I contacted Google about a developer who had passed before their domain expired, and they were able to lock out the domain from pulling anything new into their cache.
Couldn't you pay pretty much any random official in a corrupt country to produce a death certificate in any name you want? Maybe it's a bigger bribe than normal, but it seems like it would be routine
So this is where I'd highlight the benefits that an actual human looked at and responded to my email (a rarity for Google), and hence could use human discretion to decide that what I indicated was indeed accurate, and not randomly from a random corrupt country. I really have to emphasize: Any security process that actually works has humans in the loop! (Security doesn't scale.)
The other thing of course, is that the domain was expiring. So similar to PyPI just accepting in the parent article that an expired domain isn't trustworthy, Google could verify shortly thereafter whether or not the domain was renewed by the developer in question.
And ultimately, you're suggesting paying off an official to pretend someone is dead, so you can block package updates to a domain, which doesn't really introduce a security issue, and of course, is trivially reversible when the person in question is, in fact, still alive. As Tony Stark would say, "Not a good plan".
I don't think you've ever dealt with the likes of US credit bureaus if you think getting something like a death announcement is "trivially reversible".
I forever am and forever will be a civil engineer somewhere in upstate New York thanks to them. Nevermind I was still in high school at the time and don't even have a shred of engineering qualifications. Whoever you are, thanks for the borrowed ladder my friend.
For a given version, yes. But the security risk here is about publishing a new (malicious) version of a previously trusted package, by taking control of an expired domain.
Say I'm using mydomain.org/abc and it's a perfectly fine package. I'm currently using v1.25.7. Two months later, I see a new version of mydomain.org/abc, v1.25.8. I will likely update to it and use it relatively confidently. But, unbeknownst to me, mydomain.org's registration expired one month ago, and a malicious actor has grabbed it in the meantime; and they have now released a malicious version of this package. Nothing in Go's security model prevents this type of attack, except that Google's package "cache" (the package repo that Go downloads things from) can be configured by Google to not provide that malicious package.
This is a major design flaw with the silly idea of using an extremely imparmenent identifier - DNS names, which can only be leased for a limited time and are automatically auctioned off after they expire - as the main identifier for something as long lived as Go packages. No other package ecosystem has this terrible design concept - even when they do use DNS, they use it only for an initial authentication, not as the only identifier.
For example, in Java's Maven repo, to publish a package org.mydomain.abc from a Maven Central account, you need to prove that you have ownership of abc.mydomain.org once when associating this package. Afterwards, the package name remains associated with your Maven Central account, forever. If you lose access to that domain name and someone else obtains, they can't go through the same steps, Maven Central won't let them, since that package name is already tied to your account.
This doesn't address availability or discoverability though. There are no upsides other than a fleeting sense of "decentralization", without any of the securities of a real decentralized protocol.
No technical solution is going to save you from an upstream going rogue and you blindly updating. The only way is to properly review your dependencies.
The problem isn't an upstream going rogue; it's an upstream going dark, and someone taking advantage of that.
Upstreams going dark happens much more often than them going rogue. A system that requires you to prove more than you just control a domain isn't as vulnerable to this problem.
The presented domain expiration model looks like .com and other global domains. What about .de, .uk and countless other country domains, each having its unique expiration policy? Will it work with them, or only with .com domains?
This largely depends on the ICANN policies and their definitions of Renewal and Registration Grace Periods.
The Renewal period is variable, but the Registration Grace Period is pretty much 30 days everywhere.
The ERRP only covers gTLDs, right? Have you seen any ICANN policies requiring ccTLDs to adopt the same grace periods. As far as I know, ccTLDs can do whatever they want.
ICANN policies only govern global domains. Country domains set their own policies; for example, .eu expiration period is 45 days, not 30.
WHO IS policies also vary wildly, for example .de domains do not show registration date in the WHO IS, so it's not possible to know if a domain was dropped and re-registered.
Keybase had good concept originally and they even had some momentum for a sec, but then they took VC money and imploded. Considering how simple system it was, I feel it should be something we could implement again (without spof)
Seems neat project, but it is missing the most characteristic feature of keybase, public identity verification? I.e. the ability to link key-pairs with social media accounts etc.
Disconcerting amount of AI-slop images on that page... not good for one of the first things I notice about a web page to be "why are the images so weird".
(I'm also not keen to follow Max to another project... they fucked up OKCupid pretty badly, and Keybase never actually had a business model, with predictable results, so I have to imagine FOKS is going to get enshittified somehow as well.)
I really liked Keybase, and do note that Keyoxide exists as an open-source project where annotations of proofs are made directly on the PGP keys and no longer requires a central point of failure. ;)
I will say there are downsides to cryptographic keys being required for updating a package: One of the biggest pain points we have in Sandstorm is we both verify authors using their PGP key (from Keybase, as it happens, it's an old project), and we have a keypair for each app which you need to update it.
The end result unfortunately is sometimes we have trivial one-line fixes for apps which are abandoned by the author, and it is very difficult to deploy said fix to end users. This can hypothetically manifest in the form of unfixable security problems. We do have a way to forcibly change the key, but it's intentionally a pain to do, and of course, is possible because ultimately the central authority has the ability to code the platform to circumvent that key anyways.
Which is to say, you do trade some security risks for other security risks, whether it's a better situation is an exercise for the reader.
My understanding is that they were acqui-hired by Zoom - probably for optics reasons, since Zoom was having a series of high-profile security incidents around then. Keybase development basically came to a standstill at that point, probably because the team got pulled away to work on Zoom projects.
That can still be caused by VC funding. Take VC money, burn money fast, runway gets too short -> look for an acquisition, even if it throws away the product. Investors can even force the founders to take that deal whether they want it or not.
A less aggressively funded business might have limped on essentially forever with the base product.
I've heard this a few times. By what mechanism do the investors do the forcing, assuming that the company is early enough that the founder aligned board is still in the majority?
It's all a question of are the founders still in power or not. Especially at a time when the company is actively looking for a cheap last-resort acquisition, I'd expect all the possible external funding to have been pumped in, at less-than-ideal terms, and diluted the founders' slice.
I've personally worked at a startup that forcibly ejected its founders. It happens.
(The startup got sold for scraps about 6 months later. The service I personally worked on kept streaming video for about a year with zero maintenance, only failing when the hardware was physically powered off. This was well after the main database had collapsed, and the web UI was inoperable, while iframe embeds kept chugging along.)
> It's all a question of are the founders still in power or not.
Plenty of "founders" decide to sell out rather than follow their original vision no matter what. It's not even necessarily the wrong thing to do. But the prospect of a liquidity event can turn an idealist's head quickly.
Because it's a bad idea! Identity is much more complicated than any sane cryptographic protocol can express. You can see why instantly when people suggest things like Metamask as a solution to the problem: durable long-term strong cryptographic identity with no account recovery.
Flawed and doesn't scale now, but wasn't that the idea behind PGP and key signing parties? Nothing enforced, but the idea was someone was supposed to verify your identity irl before they signed your key.
I think that is mainly because crypto or anything crypto related is tainted bu scams etc. So a regular user just doesnt have the same trust. Another problem is crypto gets attackwd way more since it also involves real money.
I think they meant cryptography not crypto currencies. I will forever hate crypto currencies for taking the entire concept of cryptography as their name and getting it associated with scams.
Domain expiration is something that's more complicated than most people realize. As an example, I'm not sure if there's a definitive source stating that auto-renew grace is part of the ERRP. In my opinion it's not and the ERRP typically won't trigger for high value domains because they'll be sold or auctioned by the registrar instead.
As far as I know, the ERRP rules describe the policies for the deletion of expired domains, which isn't required, so working off the auto-renew grace status was a good choice here. Most people don't realize that expired domains aren't guaranteed to go through the ERRP lifecycle [1].
> You should be aware that during the auto-renew period, the domain name may be available to third parties for registration, depending on your registrar's terms of service. You may also run the risk of having your domain name auctioned to a third party by your registrar during this period (depending on your terms of service)
The process described here sounds like a pretty reasonable approach to a hard problem. It won't catch everything, but it's a good approach and it's nice to see some effort put into the issue.
1. https://www.icann.org/resources/pages/registrant-about-errp-...
This isn’t limited to just domains, though it’s good to consider. What happens when Google, Microsoft, or anyone else recycles unused accounts? Unfortunately for them, it seems like email addresses have been so tightly coupled with identity that it seems unreasonable that an address could be reused after any period of account inactivity.
I was angry when I realized my hotmail account I used from 2000 all the way through the 2010s got wiped by Microsoft. I was using gmail more, but still someone else got my old email and all the emails I used to receive along with it I'm sure.
Google wont allow you to register with the deleted/suspended/inactive email address
I wish Microsoft had done this to my deleted Hotmail, instead some random person got my email, and potentially access to every website I ever registered to with said email...
Why is Google notifying me that they'll delete the account associated with <some email address that i do own> lately then?
They'll delete the storage, or make that email available for new registrations?
Google's support page says they don't recycle usernames, ever so once an email is registered that's it, even after they delete the account. However, the by product of that is you won't be able to re-register that email. Once its gone, its gone forever.
FWIW I am unable to register a gmail for an account I deleted probably 8 years ago at this point. That said I don't know if there is anywhere where it explicitly outlines if it is or is not possible.
Ah so I either click on it and recover password or give up on it. Decisions decisions...
Oh funny. They started the recovery process then wanted me to add a phone number so they can send a recovery code. In spite of them first sending a recovery code to the email that I do control and me entering it.
I pressed 'try another way' and they told me they don't have enough information to prove the account is mine.
Fuck off Google basically. They could at least be honest and state that a phone number is required, instead of pretending that it's for verification.
Even if you provide a phone number, it will never send the required code or information and you will still be locked out of your account.
That is how I am locked out of a gmail account... eventhough I have the right username/password, and backup email, and typed in a phone number, Google won't let me back in.
yeah, cheaper to just denylist that username and remove the storage.
Google is fucked up. I can't get into my old Gmail even with the correct password.
Don't use GMail
This is exactly the kind of proactive security thinking we need more of. Supply chain attacks are getting more sophisticated, and preventing domain resurrection attacks is smart defensive strategy. Too many security incidents happen because someone thought "that'll never happen to us." PyPI is thinking ahead about attack vectors before they become widespread problems.
One of the places this worried me the most was Golang, where domains for repositories are used as a package source. Credit where credit's due, when I contacted Google about a developer who had passed before their domain expired, and they were able to lock out the domain from pulling anything new into their cache.
On the other hand it's pretty crazy you could just get a domain blacklisted like that
It was quite possible to independently prove my report was genuine. I am confident they didn't take my word for it.
I give Google a lot of well-deserved criticism, but they handled this issue pretty well and quite promptly.
Couldn't you pay pretty much any random official in a corrupt country to produce a death certificate in any name you want? Maybe it's a bigger bribe than normal, but it seems like it would be routine
So this is where I'd highlight the benefits that an actual human looked at and responded to my email (a rarity for Google), and hence could use human discretion to decide that what I indicated was indeed accurate, and not randomly from a random corrupt country. I really have to emphasize: Any security process that actually works has humans in the loop! (Security doesn't scale.)
The other thing of course, is that the domain was expiring. So similar to PyPI just accepting in the parent article that an expired domain isn't trustworthy, Google could verify shortly thereafter whether or not the domain was renewed by the developer in question.
And ultimately, you're suggesting paying off an official to pretend someone is dead, so you can block package updates to a domain, which doesn't really introduce a security issue, and of course, is trivially reversible when the person in question is, in fact, still alive. As Tony Stark would say, "Not a good plan".
I don't think you've ever dealt with the likes of US credit bureaus if you think getting something like a death announcement is "trivially reversible".
I forever am and forever will be a civil engineer somewhere in upstate New York thanks to them. Nevermind I was still in high school at the time and don't even have a shred of engineering qualifications. Whoever you are, thanks for the borrowed ladder my friend.
Reminds me of this presentation from a decade ago https://www.youtube.com/watch?v=9FdHq3WfJgs
go’s lockfiles include cryptographic hashes which prevent even Google from maliciously replacing packages in the cache.
For a given version, yes. But the security risk here is about publishing a new (malicious) version of a previously trusted package, by taking control of an expired domain.
Say I'm using mydomain.org/abc and it's a perfectly fine package. I'm currently using v1.25.7. Two months later, I see a new version of mydomain.org/abc, v1.25.8. I will likely update to it and use it relatively confidently. But, unbeknownst to me, mydomain.org's registration expired one month ago, and a malicious actor has grabbed it in the meantime; and they have now released a malicious version of this package. Nothing in Go's security model prevents this type of attack, except that Google's package "cache" (the package repo that Go downloads things from) can be configured by Google to not provide that malicious package.
This is a major design flaw with the silly idea of using an extremely imparmenent identifier - DNS names, which can only be leased for a limited time and are automatically auctioned off after they expire - as the main identifier for something as long lived as Go packages. No other package ecosystem has this terrible design concept - even when they do use DNS, they use it only for an initial authentication, not as the only identifier.
For example, in Java's Maven repo, to publish a package org.mydomain.abc from a Maven Central account, you need to prove that you have ownership of abc.mydomain.org once when associating this package. Afterwards, the package name remains associated with your Maven Central account, forever. If you lose access to that domain name and someone else obtains, they can't go through the same steps, Maven Central won't let them, since that package name is already tied to your account.
This doesn't address availability or discoverability though. There are no upsides other than a fleeting sense of "decentralization", without any of the securities of a real decentralized protocol.
A malicious actor could, however, quite trivially add one to the version number. ;)
No technical solution is going to save you from an upstream going rogue and you blindly updating. The only way is to properly review your dependencies.
The problem isn't an upstream going rogue; it's an upstream going dark, and someone taking advantage of that.
Upstreams going dark happens much more often than them going rogue. A system that requires you to prove more than you just control a domain isn't as vulnerable to this problem.
go.mod keeps checksums, so this should come up easily for downstream consumers.
However, when devs change dependencies, an innocent `go mod …` might update to a new (compromised) version of a dependency.
This is why URI based imports make little sense to me, honestly.
The presented domain expiration model looks like .com and other global domains. What about .de, .uk and countless other country domains, each having its unique expiration policy? Will it work with them, or only with .com domains?
This largely depends on the ICANN policies and their definitions of Renewal and Registration Grace Periods. The Renewal period is variable, but the Registration Grace Period is pretty much 30 days everywhere.
https://www.icann.org/en/contracted-parties/consensus-polici...
Here's an example from denic.de: https://www.denic.de/en/domains/de-domains/domain-deletion#c...
The ERRP only covers gTLDs, right? Have you seen any ICANN policies requiring ccTLDs to adopt the same grace periods. As far as I know, ccTLDs can do whatever they want.
ICANN policies only govern global domains. Country domains set their own policies; for example, .eu expiration period is 45 days, not 30.
WHO IS policies also vary wildly, for example .de domains do not show registration date in the WHO IS, so it's not possible to know if a domain was dropped and re-registered.
All of this because we still haven’t solved durable long-term strong cryptographic identity on the internet.
(Actually we have, but nobody wants to make people install Metamask or similar to log into websites.)
Keybase had good concept originally and they even had some momentum for a sec, but then they took VC money and imploded. Considering how simple system it was, I feel it should be something we could implement again (without spof)
One of the founders is doing exactly that: https://foks.pub/
Thread with comments announcing it: https://news.ycombinator.com/item?id=44520419
Seems neat project, but it is missing the most characteristic feature of keybase, public identity verification? I.e. the ability to link key-pairs with social media accounts etc.
Disconcerting amount of AI-slop images on that page... not good for one of the first things I notice about a web page to be "why are the images so weird".
(I'm also not keen to follow Max to another project... they fucked up OKCupid pretty badly, and Keybase never actually had a business model, with predictable results, so I have to imagine FOKS is going to get enshittified somehow as well.)
I really liked Keybase, and do note that Keyoxide exists as an open-source project where annotations of proofs are made directly on the PGP keys and no longer requires a central point of failure. ;)
I will say there are downsides to cryptographic keys being required for updating a package: One of the biggest pain points we have in Sandstorm is we both verify authors using their PGP key (from Keybase, as it happens, it's an old project), and we have a keypair for each app which you need to update it.
The end result unfortunately is sometimes we have trivial one-line fixes for apps which are abandoned by the author, and it is very difficult to deploy said fix to end users. This can hypothetically manifest in the form of unfixable security problems. We do have a way to forcibly change the key, but it's intentionally a pain to do, and of course, is possible because ultimately the central authority has the ability to code the platform to circumvent that key anyways.
Which is to say, you do trade some security risks for other security risks, whether it's a better situation is an exercise for the reader.
> but then [Keybase] took VC money and imploded
My understanding is that they were acqui-hired by Zoom - probably for optics reasons, since Zoom was having a series of high-profile security incidents around then. Keybase development basically came to a standstill at that point, probably because the team got pulled away to work on Zoom projects.
That can still be caused by VC funding. Take VC money, burn money fast, runway gets too short -> look for an acquisition, even if it throws away the product. Investors can even force the founders to take that deal whether they want it or not.
A less aggressively funded business might have limped on essentially forever with the base product.
I've heard this a few times. By what mechanism do the investors do the forcing, assuming that the company is early enough that the founder aligned board is still in the majority?
It's all a question of are the founders still in power or not. Especially at a time when the company is actively looking for a cheap last-resort acquisition, I'd expect all the possible external funding to have been pumped in, at less-than-ideal terms, and diluted the founders' slice.
I've personally worked at a startup that forcibly ejected its founders. It happens.
(The startup got sold for scraps about 6 months later. The service I personally worked on kept streaming video for about a year with zero maintenance, only failing when the hardware was physically powered off. This was well after the main database had collapsed, and the web UI was inoperable, while iframe embeds kept chugging along.)
> It's all a question of are the founders still in power or not.
Plenty of "founders" decide to sell out rather than follow their original vision no matter what. It's not even necessarily the wrong thing to do. But the prospect of a liquidity event can turn an idealist's head quickly.
Because it's a bad idea! Identity is much more complicated than any sane cryptographic protocol can express. You can see why instantly when people suggest things like Metamask as a solution to the problem: durable long-term strong cryptographic identity with no account recovery.
Flawed and doesn't scale now, but wasn't that the idea behind PGP and key signing parties? Nothing enforced, but the idea was someone was supposed to verify your identity irl before they signed your key.
I think that is mainly because crypto or anything crypto related is tainted bu scams etc. So a regular user just doesnt have the same trust. Another problem is crypto gets attackwd way more since it also involves real money.
I think they meant cryptography not crypto currencies. I will forever hate crypto currencies for taking the entire concept of cryptography as their name and getting it associated with scams.
Which is of course because we have not solved the lost key problem.
I think SigSum is trying to gain some traction in this space.
https://www.sigsum.org/
great!
this was one of the major problems with doing maven style domain based namespacing
namespaces when?!
dupe of https://news.ycombinator.com/item?id=44942432