[DNSOP] Light weight encrypted DNS proposal

Vint Joseph <vintjoseph871@gmail.com> Wed, 14 August 2024 22:06 UTC

Return-Path: <vintjoseph871@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF983C18DB86 for <dnsop@ietfa.amsl.com>; Wed, 14 Aug 2024 15:06:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.857
X-Spam-Level:
X-Spam-Status: No, score=-1.857 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27Wf6CWwFL7C for <dnsop@ietfa.amsl.com>; Wed, 14 Aug 2024 15:06:53 -0700 (PDT)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BDF1C18DB98 for <dnsop@ietf.org>; Wed, 14 Aug 2024 15:06:53 -0700 (PDT)
Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4280ca0791bso1470565e9.1 for <dnsop@ietf.org>; Wed, 14 Aug 2024 15:06:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723673211; x=1724278011; darn=ietf.org; h=cc:to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=5q/Iexzif6hv29SfmFg0l9qYZFPtJgvdLbBh2Gjg41Q=; b=Fsnn5sAUg09lj1etTFoU5wWiH1uk9aZ9BziH00U6+5g/J3AMsr3V+SnqAPzQ0cpEch 0JMh0pU9svJHqMJJZf2oseEaiB5nSjhzjTqmeTFdhsWteZWDBrETGWWGVsndBiLcqXXV zLRE1xPkzSg10x5NY9OdIni/icnAPu/EQhdLH17g4Z3JCKeSeBEvFpEWEQNTfNohaTfX /hEm3v9mbOWF7EXBTs1Uyg0KD2ahxeZuqyeWrOGkSqOrulBff74DMFMsJLKKZs4tOUA6 z05QBmpkHe3KMG26gf2Lc0sBCPrK8UrhJn6LjsZh5ksZa7iZTSztRx03s4Kkr6+NjLSE xo8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723673211; x=1724278011; h=cc:to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5q/Iexzif6hv29SfmFg0l9qYZFPtJgvdLbBh2Gjg41Q=; b=nFssBsGIJtk4DHo9XuKLI6oNwapbHqJP5hSZhCmycnP9PSD9HL3QNuot9ThtyXqyLC Zdqm1PaKHlESCr1bVtXq4oR/XesymJCC+0hmKUAyeERl8K/TbHcNzXtRzuhNQxr9nYiG f+K779clanvn6k2tx2UrawrzylRHyfaTtG/3eF4g2N3IReiQIskdtl4z37o3JpfbooVG UF0I/FonkleT0YBNaqArn+tP7+VT/78HldMls4iSjDl8dQxyT69ZeSteFrL2282ti7nE K4kJxg7jY75L4Vpvn2YSrNPzDP1vLDvx8x5mQfe8mUUyl2rFXNaJp7GM+tz18jDt9ngY OT+g==
X-Gm-Message-State: AOJu0Yy5IGefIqkTY2PrprjI22/8AcrQxZCnx/w17tLwdQ3cgoW+u/kC 82aNuZ84hbJi1nEwJshhuITp8190xUeGzfjKg5OjcLj08MA9T9fcuwA/w8+ZdPdHmS9k8MIKviy A7J5SYgkMUPh9ryyUPNq6ohLh1vRS6pdM
X-Google-Smtp-Source: AGHT+IGSLxAs6nzgGbWLUwUOsUbsOOT/p47sKlys1tnMyCSnAv0Usyjy1RDsK/oCe3xbDDMpD5SBo5TPZbxmnGtYENI=
X-Received: by 2002:a05:600c:1c9f:b0:427:9a8f:9717 with SMTP id 5b1f17b1804b1-429dd1ed488mr30165045e9.0.1723673211104; Wed, 14 Aug 2024 15:06:51 -0700 (PDT)
MIME-Version: 1.0
From: Vint Joseph <vintjoseph871@gmail.com>
Date: Wed, 14 Aug 2024 15:06:39 -0700
Message-ID: <CACWojzWRoVgMzTfu_LtOKEaky+LjqfrtrxjiQCmU3B3dFHVTQw@mail.gmail.com>
To: dnsop@ietf.org
Content-Type: multipart/alternative; boundary="00000000000074f627061fabf177"
Message-ID-Hash: YINX3EJM56F5QPQFAM53WU65TIWLESIW
X-Message-ID-Hash: YINX3EJM56F5QPQFAM53WU65TIWLESIW
X-MailFrom: vintjoseph871@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "mohit06jan@gmail.com" <mohit06jan@gmail.com>, "ethan.hamadeh@gmail.com" <ethan.hamadeh@gmail.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Light weight encrypted DNS proposal
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/bgv84V519XDahT4cxN6LPCYzjRU>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

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