Hi there! On 15 Aug 2024, at 00:17, Vint Joseph <vintjoseph...@gmail.com> wrote:
> 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. "Preshared" is easy to type but more difficult to implement. Most DNS servers have no prior knowledge of the clients that might send them queries. How do you distribute a key to all possible clients in such a way that it can be trusted to protect privacy? How do you manage the lifecycle of such a key, imagining that it needs to be possible to change it, e.g. due to key compromise? What additional failure modes would such key management introduce? > When the client needs a DNS response, it generates a key pair consisting of a > private key C and a public key G^C. Key generation on every query does not seem lightweight, e.g. for a client such as a busy DNS resolver that sends millions of queries per second to authoritative servers, or for a resource-constrained single-user device that sends hundreds of queries per second to a resolver. > 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. If this proposal was implemented, it would amplify the work required on a DNS server to process an incoming query. Amplification of resources required per query is generally to be avoided since it presents an opportunity for denial of service attacks. What mitigation do you imagine for this problem? > 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! I suggest you review the specifications for dnscrypt, DoH, DoQ and DoT which are (to varying degrees) already implemented and deployed, and consider (a) what they worried about that you don't, and whether you are missing something and (b) whether there is actually a need for a more lightweight mechanism than what already exists. More generally, if you want to share a proposal with an IETF working group I suggest writing it up as thoroughly as you can in the form of an internet-draft. This is the normal way that proposals are reviewed by working groups. If you look around ietf.org you should find various tutorials to guide you on how to write and submit an internet-draft. Joe _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
