Re: [core] [dns-privacy] WGA call for draft-lenders-dns-over-coap

Ted Lemon <mellon@fugue.com> Mon, 15 August 2022 15:11 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A77FC159A38 for <core@ietfa.amsl.com>; Mon, 15 Aug 2022 08:11:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.905
X-Spam-Level:
X-Spam-Status: No, score=-6.905 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20210112.gappssmtp.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 WjESUsvQmqQR for <core@ietfa.amsl.com>; Mon, 15 Aug 2022 08:11:43 -0700 (PDT)
Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B416EC14F73B for <core@ietf.org>; Mon, 15 Aug 2022 08:11:43 -0700 (PDT)
Received: by mail-qv1-xf2a.google.com with SMTP id l8so5534982qvr.5 for <core@ietf.org>; Mon, 15 Aug 2022 08:11:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc; bh=/4UVe80X2UfZ5vAOUFXVcaH5FUfY4Xfz3aBFvhApFqI=; b=h0lnB0yFB7UrtvUqWyyCJJbJHvVeT/X/GaQAdVn/w/fJLoMDeSBcdCbCgxUSP0oqtq 1HngyBOODZkVB0d6hvkN661vofGMeTAN7l50Hw629Fj2P/37oHS2tPfvpMJhw4rQmbKy 3egUJEctxCk+uVFqbH2R3Q6T3tyKN9O6dSTKjNGJUQmyIULUpWTJlBk6w51InJO0Pffv XsjmqqPa3iuougdKfr1LSYbHXC1cQZiMt/W/yYAsCtUAZX/ArhKc9lO+563VNiWenA3e sr60Er8Y02bier3UjdzUWSFX5dOSjKZ7GO6XhCytLrhbPyKZNFRRIyz46BfFJYTnBOpH +Wdw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc; bh=/4UVe80X2UfZ5vAOUFXVcaH5FUfY4Xfz3aBFvhApFqI=; b=Mye1g+k9GbW0lIZkwolk3i1t07swTBt6mUPXIAQq32JLWu39WvM8huJLuO/aEqIiFg 2dBymB6f0oLBn6XqmFwk5OsGK16uGFvsdavisOd7Qc4QVzAN9JIzfi47GLYHGYekUoq7 ksIhPGC4K0H+IP8rh58S3YcOg+h4wvlgpHtwYBfU9BXeMxOm9TAdopPWNFvwWlQboiuA DSakHHVateBbftsLarRzVkxE7dV8KlA/xDqlPHcxUYncCoIqhtwRwZEobQsUiyEV5ezm qy1DlzWUnUV03YssEM7Z773mk3usiW2pH0GShgPL/UI8wudjcn8eaj54LKaXhmOh+HGP gzug==
X-Gm-Message-State: ACgBeo1nGhzyVPWPlgqdXlE6LJZMieJ8he2sMpXHzZ+X81bjwrfXVk2P 6SbE1z4cNtX2XuLO9qskMeIhU9t0WCj7Yw==
X-Google-Smtp-Source: AA6agR6vGbwsxje/gmN20TBg1QQdOcdmxjQibH609Y+mH14yVjcGgdRhX8OU0sZUhApgC1TRNrPR7g==
X-Received: by 2002:a05:6214:5299:b0:47e:89e9:e27b with SMTP id kj25-20020a056214529900b0047e89e9e27bmr14248265qvb.52.1660576302326; Mon, 15 Aug 2022 08:11:42 -0700 (PDT)
Received: from smtpclient.apple ([2601:18b:300:3380:7463:c3e9:af1f:efff]) by smtp.gmail.com with ESMTPSA id cp5-20020a05622a420500b0031f41ea94easm7915487qtb.28.2022.08.15.08.11.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 15 Aug 2022 08:11:41 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-29E2FB58-CCB8-4331-A150-F8A26990922A"
Content-Transfer-Encoding: 7bit
From: Ted Lemon <mellon@fugue.com>
Mime-Version: 1.0 (1.0)
Date: Mon, 15 Aug 2022 11:11:41 -0400
Message-Id: <A2829FB5-7FAB-4290-83D7-FC548CA730F1@fugue.com>
References: <CADyWQ+F2QAmZSnMAg9_-jCMXFmP7E+cdzNurU6d+tya1e9Tyjg@mail.gmail.com>
Cc: Jaime Jiménez <jaime@iki.fi>, core@ietf.org, dns-privacy@ietf.org, dnsop@ietf.org
In-Reply-To: <CADyWQ+F2QAmZSnMAg9_-jCMXFmP7E+cdzNurU6d+tya1e9Tyjg@mail.gmail.com>
To: Tim Wicinski <tjw.ietf@gmail.com>
X-Mailer: iPad Mail (19F77)
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/AO0c6nm79yyItFjuCL9oZfzT6NA>
Subject: Re: [core] [dns-privacy] WGA call for draft-lenders-dns-over-coap
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2022 15:11:47 -0000

This is a good question. I think we’d want to understand what the actual use case is for DNS-over-CoAP before proceeding with this, since DNS-over-DTLS would obviously be less costly to implement.  The stated use case of this document is to encrypt DNS packets, which is already addressed by DNS-over-DTLS, so if that’s the only motivation for this work, it doesn’t seem like something the IETF should be doing.

I’m sure one argument for DNS-over-CoAP is that on-path caching provides some benefit, but it also quite likely breaks the semantics of DNS, so it’s not clear to me that this is actually a good idea. I suspect the thing you need to build to make this work well is a lot more complex than simply a CoAP encapsulation. If this is an important use case, then it might be better to just put a DNS cache at that point in the path; it seems unlikely that the benefit of leveraging an existing CoAP caching strategy would justify the problems such a strategy would create.

I’d be curious to know if there’s a way to actually compress a DNS packet using CoAP, and that could then make the dns-over-coap use case more interesting. However, the current proposal doesn’t do that, so what it appears to really be doing is adding a layer of complexity and extra bytes to the packet.

Sent from my iPad

> On Aug 15, 2022, at 11:01 AM, Tim Wicinski <tjw.ietf@gmail.com> wrote:
> 
> 
> DPRIVE is also a fine location.
> 
> Has anyone implemented DNS over DTLS for your use case? 
> 
> tim
> 
>> On Mon, Aug 15, 2022 at 6:04 AM Jaime Jiménez <jaime@iki.fi> wrote:
>> CCing the right DNSOP mailing list now. 
>> 
>> 
>> On 15.8.2022 11.26, Jaime Jiménez wrote:
>>> Dear CoRE WG,
>>> 
>>> We would like to start the call for adoption on draft-lenders-dns-over-coap. 
>>> The draft defines a protocol for sending DNS messages over secure CoAP (DTLS and/or OSCORE). The draft was discussed during IETF114 and on IETF113 and was well-received by the group.
>>> 
>>> https://datatracker.ietf.org/doc/draft-lenders-dns-over-coap/ 
>>> 
>>> During the last IETF meeting there were no objections for adoption so we confirm this now on the mailing list. Please let us know if you support adopting this draft. As many people will still be on vacation, we the WGA call will last a couple of weeks, ending the 1st of September.
>>> 
>>> Note that DNSOP and DPRIVE are in the loop as the draft is relevant for their working groups too.
>>> 
>>> BR,
>>> -- 
>>> Jaime Jiménez
>>> 
>>> 
>>> _______________________________________________
>>> core mailing list
>>> core@ietf.org
>>> https://www.ietf.org/mailman/listinfo/core
>> -- 
>> Jaime Jiménez
>> _______________________________________________
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core