Add signatures directly of the DNS record

[Divide-By-0]

Hey, currently, I have to directly talk to a resolver to get a DNS validation, so if they are not live, I cannot use their past responses, and their capacity is limited by their bandwidth. This can be improved by having a cryptographic signature not jut of their public key, but of the result of their DNS retrieval as well. Then, other users can relay that message to other users, and it still holds the portable provenance of that answer. This means my infrastructure can scale the result to all of our users after just one reaponse of the resolver, and they don't have to trust us.

With the current system, since it does the symmetric encryption, that value cannot be relayed past the original user, since the middle hop could have forged the response as they have the symmetric key as well. We would find such a signature extremely useful in production for zk email as it would give us an end to end chain of provenance.

[jedisct1]

I must confess that I don't follow...

Hey, currently, I have to directly talk to a resolver to get a DNS validation

What do you mean by DNS validation? Are you referring to DNSSEC? What is talking to a resolver? What is "I"? A proxy? A relay? A cache? A client?

In the DNSCrypt protocol, certificates are retrieved using a DNS query, and all the included certificates are signed, not just public keys. That can be safely cached and relayed by third-party caches if necessary. In fact, this is what DNSCrypt relays already do in order to defend against fingerprinting.

With the current system, since it does the symmetric encryption

It doesn't. Certificates only contain public keys, and clients can derive new key pairs, and thus shared secrets as often as they want (see dnscrypt_ephemeral_keys in dnscrypt-proxy).

that value cannot be relayed past the original user

What is a "value"? DNSCrypt relays can't forge anything, as they don't know about the server nor the client private keys.

Without buzzwords, what problem are you trying to solve? Are you looking for proxy reencryption?

[Divide-By-0]

Right, sorry, let me add more details. Not quite proxy re-encryption.

The primary functionality I am looking for is the ability to verify that someone trustworthy has attested to the value of a DNS record, even if the website does not have DNSSEC enabled. I am a client, looking for functionality from resolvers. I want to serve their digital signatures to the public to reduce reliance on us as a central provider. For instance, on our dkim lookup site, dkim-lookup.vercel.app right now users have to trust that we uploaded the value for say gmail.com correctly.

If gmail had DNSSEC on, this verification would be easy. However, they don't. In place of that, I am hoping that 100 resolvers all giving a signature that it is in fact correct is a good enough "double check" on us serving those values.

Specifically, pretend all lookups on this site also include signatures of the DNS record from say 100 resolvers, (ideally timestamped) of the response that I claim. As the central owner of this site, now I can't just fudge a bunch of DNS DKIM records however I would like, because I would have had to compromise 100 resolvers as well [ideally these are the highest reputation resolvers].

The thing is, just sending the DNS over an encrypted channel doesn't quite give me this functionality. Since DNSCrypt is interested in helping make DNS lookups online more trustworthy, I was hoping that this might be a worthy addition to the protocol.

that value

Sorry I am discussing the value of a specific DNS record here.

[jedisct1]

If I understand correctly, you would like DNS caches to add, to every response, an extra record with a timestamp, as well as an extra record that is a signature of other records + the timestamp.

That can be useful to fetch a decrypted response from a secondary cache, and still have the ability to check that it originally comes from a given cache.

But in the context of the application you describe:

100 resolvers all giving a signature that it is in fact correct is a good enough "double check" on us serving those values

That wouldn't be useful.

Resolvers are not guaranteed to serve the same response for a given query. First, when a zone is updated, the update is not atomic, so authoritative servers and caches will send different responses.

Some records also have a 0 TTL, so every query can return a different response.

Servers also frequently return different IP addresses for load-balancing purposes, or for geographic steering. By design, you can't expect 100, or even 2 servers to return the same responses.

The only thing that can be compared are DNSSEC public keys used to sign zones. And even then, this is tricky due to key rotation, that requires querying parent zones.

[Divide-By-0]

That can be useful to fetch a decrypted response from a secondary cache, and still have the ability to check that it originally comes from a given cache.

Yup! That was the original thing I was trying to get to, but this is phrased much better haha.

Resolvers are not guaranteed to serve the same response for a given query. First, when a zone is updated, the update is not atomic, so authoritative servers and caches will send different responses.

Yeah! So for DKIM, because most (all that I've seen) providers have a single key per mail service they use (and thus per dkim selector), so likely they'd have global consensus for those. During rotation (once every 6 months or so), yes, likely servers would disagree and then like 1-48 hours later they'd be synced again. That information is also very useful for us because then we can freeze certain operations that take these email proofs, until the keys are updated; but 178/180 days everyone should be in sync which is still a major help for us. We are OK if servers return different IPs; we only care about the TXT records corresponding to a specific domain, which should be globally consistent! So I agree this specific usecase would likely not make sense for usual DNS resolutions, but it would be very useful for our usecase (although the secondary caching idea would probably be useful for the regular DNS usecase as well :)

[jedisct1]

That is independent from the DNSCrypt protocol, especially since a key feature of DNSCrypt is that queries and responses are not inspected nor modified.

It would rather be a feature that DNS caches could implement. The transport protocol is irrelevant.

[Divide-By-0]

That is independent from the DNSCrypt protocol, especially since a key feature of DNSCrypt is that queries and responses are not inspected nor modified.

It would rather be a feature that DNS caches could implement. The transport protocol is irrelevant.

Got it! What is the best project for me to reach out to here for this, or repo to contribute to?

[alexhooketh]

Hi @jedisct1 !

We at zk-email would like to propose a soft upgrade to the DNSCrypt protocol.
While DNSCrypt v2 fully prevents message tampering, the authenticity of the messages can only be proven by the sides of the connection, that is, only client and server are sure that other side's messages aren't modified. This happens because of X25519 used in the protocol. Such approach is severely limited in the sense that the messages' authority cannot be proven outside of the channel - the client can forge server messages and vice versa.
For example, zk-email, being a project based on smart contracts, needs a way to obtain DNS records without trusting a federated oracle. If there was a way to cryptographically prove the authenticity of DNS nameservers' messages, it would be possible to implement a quorum-based system that uses a set of the nameservers as a source of trust.

We propose an idea of soft, backward-compatible protocol upgrade. It's possible to implement such signature-backed system using additional information RRs in the DNS protocol. They aren't normally read by DNSCrypt v2 client implementations, meaning that a client that does not support the soft upgrade will simply ignore them. The opposite is also true: no existing client implementations check or enforce minor version of the protocol, so the servers that do implement the upgrade can use it to signal its support to clients that are looking for signature-backed connections.
What does it mean? We can implement the upgrade, say, v2.1, that does not require servers and clients to upgrade their backends. v2.1 clients will be able to interact with v2.0 servers and vice versa. Thanks to minor versioning and ARs, v2.1-specific data will simply be ignored by older clients.

Why is standardisation necessary? If the soft upgrade will only be used by our project, its functionality will be isolated in our infrastructure. However, standardisation will allow other projects looking for message authenticity functionality to adopt DNSCrypt. We're interested in promoting DNSCrypt in the ecosystem and we'll work with major servers to adopt it in their infrastructure.

if you're willing to allow improvements to your protocol, we are ready to fully run the development of a standard and the necessary updates for all major implementations of the protocol, such as dnscrypt-proxy, SecureDNS, YourFriendlyDNS, and more, on our own. If you have questions, feel free to ask us anything. Thanks in advance!

[jedisct1]

Beyond the DNSCrypt protocol, that doesn't seem trivial, both from a technical and from a deployment perspective.

A new record type for these signatures needs to be defined. Given the inertia of DNS standard bodies, especially when you're not part of their private club, good luck with that. But we can ignore that, and just pick an arbitrary OPT extended record type. Or abuse the existing SIG(0) record type, even though it's assumed to be only used in queries.

Then, we need to find a canonical way to represent the RR set to be signed, because every intermediate can reorder RRs. The OPT section is also going to be an issue, since EDNS0 may or may not be added according to the packet size (which is going to change with the addition of the signature). All names also need to be normalized in order to be compatible with 0x20 random mangling.

I'm not aware of any existing document nor proposal about canonicalizing DNS RR sets, so the first thing to do would be to work on that.

Then, there's the question of TTLs. Caches must decrease TTLs. So, TTLs can't be signed. It also means that caches can keep an old record alive forever. Not sure how that could be solved. Or a copy of TTLs as originally seen by the signer should be added to responses as well. That can be done, especially after RRs have been canonicalized, but that looks like a lot of work.

Finally, there's the deployment issue. Adding these signatures requires parsing packets, encoding the RRs in a canonical way, computing the signature, and adding the new RR to the original packet. This is going to have a significant CPU impact, for niche use cases. So it is very unlikely that existing public resolvers would enable this.

In practice, the protocol would only be used by resolvers specifically operated to serve the ZK Email application.