Also see DJB's https://dnscurve.org/
CurveCP came before QUIC: https://curvecp.org/ Witold had prepared a draft some years ago of a method: https://datatracker.ietf.org/doc/draft-krecicki-dprive-dnsenc/ There's https://dnscrypt.info/protocol/ that secures client->resolver traffic. There are many such roll-your-own schemes. They can provide some advantages when they're prepared specially for DNS such as the possibility of fewer roundtrips. But a danger of rolling-your-own is that it would not have received the same kind of security review as a widely adopted transport layer security protocol would have. Mukund On Thu, Aug 15, 2024 at 04:35:45PM +0200, Martine Sophie Lenders wrote: > Hi Vint, > > are you aware about [1]? With OSCORE [2] and EDHOC [3] it pretty much aligns > with your idea, as far as I can see, and would also provide you with a key > exchange mechanism for free. > > Best > Martine > > [1] https://datatracker.ietf.org/doc/draft-ietf-core-dns-over-coap/ > [2] https://www.rfc-editor.org/rfc/rfc8613.html > [3] https://www.rfc-editor.org/rfc/rfc9528.html > > On 15.08.24 00:06, Vint Joseph wrote: > > Hello All, > > > > I hope you're all doing well. > > > > We wanted to share an idea regarding encrypted DNS and get your thoughts > > on it. Our goal is to make the setup for encrypted DNS as simple as our > > current DNS setup. Here are a few key points: > > - Simplicity: Ideally, the setup should be as straightforward as > > possible, using UDP and only one or two packets. > > - Cost Efficiency: The encryption and decryption processes should not > > introduce significant overhead. > > - Stateless Approach: Maintaining state on both the client and server > > sides is costly. While we might not be able to completely move out of > > stateless ideas, we try to maintain this core concept > > - UDP Benefits: Using UDP can help avoid the head-of-line blocking > > issues we see with TCP. > > - Considering QUIC: While QUIC is a potential solution, it has its own > > complexities, including retransmission mechanisms. We're okay with some > > packet loss if retransmitting DNS queries remains simple (one or two > > packets). > > - Crypto Agility: This idea prioritizes simplicity and doesn't fully > > address the need for crypto agility. > > I would greatly appreciate your input on this approach and any > > suggestions you might have for improvement. > > > > The core idea/synopsis > > We plan to implement a system using elliptic curve cryptography. A > > preshared key, referred to as the public key G^S, is distributed from > > the dns server to the client. The server retains the private key S and > > the corresponding public key G^S, while the client receives the public > > key G^S. When the client needs a DNS response, it generates a key pair > > consisting of a private key C and a public key G^C. The client then > > sends a DNS request encrypted with the shared key G^CS and includes its > > public key G^C in the DNS extension. Upon receiving the public key G^C, > > the DNS server computes the shared key G^CS using its private key S and > > the client's public key G^C. These are ephemeral keys, ensuring that > > each DNS packet has its own session keys. The DNS server responds to the > > DNS query and sends the DNS response encrypted using G^CS. If the DNS > > server plans to change the keys, then a public key G^S1 is sent to the > > client , in the response packet. But these are optimizations which can > > be done later. > > Thank you and I'm looking forward to your feedback! > > > > Best regards, > > Vineeth > > > > _______________________________________________ > > DNSOP mailing list -- dnsop@ietf.org > > To unsubscribe send an email to dnsop-le...@ietf.org > _______________________________________________ > DNSOP mailing list -- dnsop@ietf.org > To unsubscribe send an email to dnsop-le...@ietf.org _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
