So I've had this floating around my mind for quite some time, but have never gotten around to thinking it through or doing a design suggestion. And probably won't for some time, so here's a bunch of notes to get started.

This starts with something you can't really get around, when you want to add a secure layer on anything:

• It is more complex to start using a DNSCrypt enabled resolver than a traditional DNS server, because you need more info than an IP to validate
• Distribution of the DNSCrypt resolver credentials needs to be done in a trusted and secure way

Right now this is, in part, solved by having an authoritative list of DNSCrypt resolvers on GitHub, with changes happening through pull requests.

Users are also free to use servers outside this list by supplying the needed info to the DNSCrypt client manually. In this case it is entirely up to the user to figure out to make sure the info they got has not been altered during transport.

This issue is also widely solved by using PKI and CA's, which the authoritative is self bases it self upon (GitHub has been validated by a CA, etc, etc).

Perceived issues:

• The GitHub list is centralized, which causes us to rely on e.g. GitHub being up, @jedisct1 being alive, having time to process pull requests, and alike
• As the list grows it can become quite a big job to keep track of pull request for changes being valid
• Clients require a mechanism to pull changes from the list, this with a built in lag depending on the frequency of polling: it shouldn't happen often, but what if a provider key needs to be changed out due for whatever reason?
• If you don't want to use the list you have to trust the e.g. the HTTPS transport of "some site", an email, be able to validate GPG signatures, etc, to get information on resolvers

So what if we could get around all of this?

The rough idea:

• The client is supplied with the IP of the DNSCrypt resolver
• Client send a regular DNS request for the PTR record of the resolver
• The resolver replies with it's service name, "resolver.service.com" for instance
• The client then constructs and sends regular DNS requests for A and TXT records for relevant info, and this time does DNSSEC validation of the replies
  • resolver.service.com A
  • pubkey.resolver.service.com TXT
  • name.resolver.service.com TXT
  • and any other info wanted and defined in the protocol
• Client now has all the needed info, has validated it via DNS/DNSSEC and can start using the resolver via DNSCrypt

What do you think?

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.

Spec says:

Client queries over TCP only differ from queries sent over UDP by the
padding length computation and by the fact that they are prefixed with
their length, encoded as two little-endian bytes.

But tcp length actualy encoded as big endian!

https://github.com/jedisct1/encrypted-dns-server/blob/641ba88ab1fd635524aee47afbba5887c52e1438/src/resolver.rs#L149-L152

I spend a hours to understand why i don't get response from server over tcp.

Should be the resolver's secret key i think

Given that there is now an IETF version, would it make sense to update the protocol and add support for it along the existing xsalsa and xchacha?

As initially pointed out by @chantra , supporting a standardized construction would be nice.

From a security standpoint, there's nothing wrong with Box-ChaChaPoly.

The construction is very boring in a good way.

No signs of any practical vulnerability was ever found, key setup is virtually free, it is highly parallelizable and gets faster with each CPU generation while remaining fast on constrained devices.

So, there's no need to change something rock solid.

However, it's an issue for specifications. Even if it's based on standardized building blocks, we have to describe how to implement it. Annex.1 in the current RFC is as large as the rest of the document and doesn't even include pseudo-code.

In practice, people just use implementations already available for their language. But it's still annoying for the specification.

We could easily add support for the IETF version of ChaChaPoly, without changing much of the protocol, not even nonce sizes. That requires one or two calls to a KDF to derive a subkey and a nonce, and using HKDF may be a bit slower than the current hchacha round, but it's not the end of the world.

An even more standard-y alternative would be to use HPKE with deterministic keys. That requires many more KDF calls, but we then wouldn't even have to explain how to compute shared keys.

HPKE comes with a few issues and open questions, though:

• Increased implementation size and complexity (even though implementations already exist for common languages)
• Slightly slower, due to more KDF calls
• Configuration (should it be part of the certificate? Shall we support all ciphers, hashes and KEMs?)
• When used with AES-GCM: cost of key setup, which can ruin performance.
• More intrusive changes to the protocol are required.

From a user perspective, there wouldn't be any benefits at all over what we currently have. On the other hand, it can help with adoption, especially if Anonymized DNSCrypt can prove to be faster than DNS over Oblivious HTTP/3 while remaining way easier to implement.

Hello,

I saw that the DNSCrypt v2 protocol intends to provide anonymized DNS requests. On privacytools.io issues tracker, someone mentioned that there may still be an issue with the SNI.

Since this is way above of my head, could someone please maybe clarify that issue? Thank you very much in advance :-)