Recently, I saw some storagenode cannot join satellite because of identity difficulty too low, 30 vs 36 minimum needed.
That node could be a veteran from 2019, it pain me but I don’t want to lower identity difficulty level.
I’m thinking of a vouch system from renowned satellites (like storj), so that reputable node could skip difficulty level and vetting time all together.
I’m aware of tag-signer, but that require an extra step (?), it may work for selected node, but would be difficult for already existing public node.
It help Storj too, now every node will try to be reputable with Storj first: you get more node, no matter what compensation you are putting.
I don’t think this through yet, just a rough idea to gouge interest.
Thanks for reading.
P/s: one detail I’m missing: I’m afraid that more satellite pop up and SNO will keep have to create new node because old node do not satisfy requirement anymore.
Another option is allow upgrade identity, old identity with difficulty level 30 can’t join the new default 36 or 42 or 45 later on, keep creating new storagenode is a spammy solution, it hard for both satellite and SNO.
P/s: the entire thing is about trust management, selected node can even have difficulty level 0, so I’m still prefer vouch system, but upgrade identity work too.
This difficulty was introduced to prevent the automatic addition of new nodes, which could otherwise be considered an attack: you planned for the satellite to handle 40,000 nodes, but received 1,000,000 in 15 minutes. What do you think will happen to your satellite?
And you suggest something even worse – register them as vetted. Great, now the attacker becomes the sole owner of all your clients’ data. And they can demand additional payment from you, while they hold your clients’ data hostage.
Also I saw somewhere that you want to remove /24 limit. Now you literally invited them to perform this attack and it can be done from the single device, like a wrt router or even weaker.
All these restrictions were created by smart people who understand cybersecurity, and yet you’re trying to weaken your satellite completely by removing all these useful features (not identical keys in satellite components, identity difficulty level, /24 filter, vetting process). What else do you want to remove to make it even more vulnerable to attackers?
Regarding the idea to restrict the vetting skip only for the old identity doesn’t make sense and I answered to the same suggestion here:
I can only add that there is no way to check that the identity is old and reputable, satellites doesn’t share this information.
I believe you are misunderstanding the intent here. A six years old node that managed to stay up on Storj’s network? That’s a far better guarantee than a freshly vetted node. And there’s a limited number of these nodes on the Storj network.
Maybe I just don’t like it when security restrictions are removed
As I mentioned before, satellites currently don’t exchange identity information, such as registration date and reputation.
However, this doesn’t change my opinion that this is a bad idea. The verification process is implemented to ensure that a node newly connected to a satellite can reliably store and transmit data today, and not at some point in the past.
Because if we want this identity to be attached by past history, we must also immediately disqualify it on all other satellites if it is disqualified on any of them, since it is now distrusted by any satellite.
This is mean to replace it: the difficulty is related to the generated private key, and to increase it the key will be regenerated, it’s a math.
Then maybe better to enable the trusting authority back. It will not stop the abuse, but you can allow to join the satellite with a lower difficulty if the identity is signed by your CA. Or, if you want also to consider the oldest, signed by Storj’s CA.
You might also allow a lower difficulty initially to have more nodes quickly, then increase it. Already joined are not checked for the difficulty as far as I know.
There is a problem with old certificate: it wasn’t mean to be a permanent.
I mean that why Let’s Encrypt change from 1 year to 3 months, and generally any CA that you can buy and frequently use over the internet last about a year, it give the opportunity to fight against new breakthrough in math, I don’t think we have that yet, worth considering.
But really, I’m looking at the practical point of this: 1 node will reduce the burden of SNO if the requirement later upgrade, otherwise we’ll have to remember which can join which..
No, I mean the identity authorize mechanism which was deprecated in Storj network - this command contact your CA using the one time authorization token and it allows to sign the identity. It’s not a CA for web hosting.
You may not setup this service and just trust identities, signed by Storj’s CA - this is unique case, because now it’s not possible to get this signature, so you will be sure that this identity is old, maybe worked with Storj and not from the attacker, because now it’s not possible to get this signature, so it cannot be abused.
Another crazy idea: you can join the identity manually using database’s war crimes. The SNO email you their NodeID(s) and you register it (them) directly in the database.
We previously had a mechanism for signing generated identities using a one-time authorization token, which we issued to each requester by email at a certain rate (for example, no more than 100 email addresses per day). This was implemented to gate new registrations—to prevent millions of nodes from being created in a single day, when we couldn’t yet estimate the load and the network could collapse under the influx. Then, when we were confident the services could handle the load, we stopped sending tokens by email, as before, and allowed them to be generated directly on the website. This still helped slow down registrations somewhat and complicated the automation process—a new token was issued only after the previous one had been used and not more than 1 email address per 24h (the email address was a part of the one-time authorization token).
Later, we confirmed that such attacks were no longer being attempted (especially after we removed a minimum monthly payout to each wallet) and removed the signing process entirely, freeing up server resources and simplifying the process for Node Operators.
I propose allowing new identities to be registered in the satellite database, even with lower difficulty, but only if they are signed by the Storj CA. You could also implement automatic vetting for such identities using tag-signers (these are labels used to identify special conditions for such identities. For example, Storj uses this in Select because they have different filtering rules for distribution, audit checks, and repairs). It’s likely possible to implement automatic vetting for these, but I don’t know the implementation details.
For Storj this is not needed, because old satellites already knows old identities. It could be a problem for a new satellite only. But as I said, we do not plan to attach a history to the identity, so each newly registered identity must be vetted. This is a two-ways process, because the satellite is also new and should prove its stability as well.
