Signed Provider records for the DHT

[aarshkshah1992]

We need to have signed provider records in the DHT so receivers can verify if the records were indeed advertised by peers marked as the providers on the records. However, this depends on https://github.com/ipfs/go-ipfs/issues/6916.

@jacobheun @Stebalien

1. Can we add this to Working Kademlia for 0.6 ?
2. What's the status on making Ed25519 the default signing ?

[jacobheun]

Can we add this to Working Kademlia for 0.6?

That is the goal, I've duplicated the 0.6 milestone here and added it for tracking.

What's the status on making Ed25519 the default signing?

This is planned for IPFS 0.6, ed25519 will be used by default.

[mikeal]

One more thing I’d like to see make it into the record is the CID prefix. It’s only two varints, but it makes the record a lot more valuable as it allows us to decode the data into an actual data structure.

Since it’s in the record it would end up being backwards compatible and could even be optional (although I’d like to see us include it by default).

[aschmahmann]

I’d like to see us include it by default

👍 especially for people that want to use graphsync instead of bitswap having the codec information is very useful.

[tabcat]

Is another goal of this to allow republishing records for the providing peer? (I would like to be able to do this)

[guillaumemichel]

No, there are no plans for this at the moment

[burdiyan]

For some reason I was 99% sure provider records were signed, and I was surprised to realize they are not. Are there any plans for this to be implemented?

I guess the risk here is only for the DHT clients, because DHT servers could lie to them. But servers themselves seem to not have the risk, because they only accept records if they come from the original peers. Is this correct?

Can signing provider records be implemented in a backward-compatible way? I believe it can, but I might be missing something.

Would a PR implementing it be considered?

[guillaumemichel]

I guess the risk here is only for the DHT clients, because DHT servers could lie to them. But servers themselves seem to not have the risk, because they only accept records if they come from the original peers. Is this correct?

Yes, that's correct!

Currently, there are no plans to implement this. However, if you’re interested in taking it on, I would be happy to review your PR. Your contribution would be greatly appreciated!

[burdiyan]

Not that we have an urgent need for it, but nice to know it's relatively easy to introduce, so maybe at some point we can get our hands on it :)

Thanks!

[Stebalien]

Note: You'll likely need to introduce a new DHT protocol version for this and will need to support both signed and unsigned records (for now). I.e.:

1. When putting provider records, put signed records if the server supports them.
2. When fetching provider records, accept both signed and unsigned.

Eventually, the old DHT protocol would be deprecated and only signed records would be allowed.

[burdiyan]

@Stebalien Is it really necessary to introduce a new protocol version? It seems like this could be a backward-compatible change. If you don't understand signatures – you don't read the field, but still apply the old rules of accepting records from the original peer only. If you do understand the signature, but the message doesn't have it – you only accept it if it comes from the original peer, if it does have a signature – you check that it matches the provider's PeerID.

[Stebalien]

It will work, but it'll double the bandwidth usage. This is already the case for signed peer records, but we tend to send around quite a few more provider records.

But you're right, it's not absolutely critical.