Should the timestamp be signed?

[snej]

In the spec I noticed that the DNS record is signed, but the timestamp isn’t. Doesn't that permit replay attacks, like a bad actor publishing someone's obsolete record with a new timestamp?

[Nuhvi]

@snej The timestamp in Pkarr design is unsigned, but indeed the Mainline DHT's BEP_0044 seq value is a signed integer, where negative values should be rejected. The only effect of that is limiting the maximum possible Timestamp to half of what u64 offers, but this is a problem for our future children 200 thousands years from now.

As for replay attacks, it is not doable, because the timestamp (the seq on the DHT) is signed. I realize now that this is not obvious in the basic design document, but it is well specified in the referenced BEP_0044.

If you prefer, you can see the implementation of preparing the thing that is being signed here

[snej]

I meant signed as in "digital signature", not as in "two's complement integer" :)

[Nuhvi]

Yeah just realized that now ... sorry it is a bit late here :D

I should have said "It is indeed signed" instead of this long paragraph.

[snej]

According to the spec, the timestamp is not signed:

signature = 64 OCTET ; ed25519 signature over encoded DNS packet

The detailed verification instructions also say the signed data starts 104 bytes from the start of the packet, I.e. after the timestamp.

So either the spec needs to be updated, or there may be a vulnerability with the timestamp.

[snej]

Yeah, it looks like the actual signing code is quite different from what the spec says.

[Nuhvi]

Yes the spec isn't clear here, and even if it said edd25519 signature over timestamp and encoded DNS packet that wouldn't be sufficient.

The signature is over the the Bencoded dictionary containing the timestamp (seq) as defined in BEP_0044.

I will update the base.md to clarify that.