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

Carsten Bormann <cabo@tzi.org> Mon, 15 August 2022 18:09 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26C72C1522DE; Mon, 15 Aug 2022 11:09:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=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
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 07gMVo-d-PzU; Mon, 15 Aug 2022 11:09:41 -0700 (PDT)
Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 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 F20BFC15256A; Mon, 15 Aug 2022 11:09:40 -0700 (PDT)
Received: from smtpclient.apple (p5089abf5.dip0.t-ipconnect.de [80.137.171.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4M62Ny0wTjzDCbZ; Mon, 15 Aug 2022 20:09:38 +0200 (CEST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.100.31\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <519510F7-032C-4BCE-AD7E-6889ABC7991D@fugue.com>
Date: Mon, 15 Aug 2022 20:09:36 +0200
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dns-privacy@ietf.org, dnsop@ietf.org, core@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <EF2A3A25-4D89-4258-9CE0-0FC9F8CC2080@tzi.org>
References: <693CE6A0-9479-4265-B3D9-ADEF9EF4B959@tzi.org> <519510F7-032C-4BCE-AD7E-6889ABC7991D@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3696.100.31)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/TKr5Czc5XgPezJ99b7Xni_eZuqI>
Subject: Re: [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Addition of privacy to the DNS protocol <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Aug 2022 18:09:47 -0000

On 15. Aug 2022, at 19:41, Ted Lemon <mellon@fugue.com> wrote:
> 
>> On Aug 15, 2022, at 1:34 PM, Carsten Bormann <cabo@tzi.org> wrote:
>> 
>> On 15. Aug 2022, at 17:11, Ted Lemon <mellon@fugue.com> wrote:
>>> 
>>> 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,
>> 
>> The main use case is systems that already implement CoAP and do not want to add machinery for some protocols that are used only for very specific purposes.
> 
> You’re going to have to construct a DNS packet. I presume CoAP is using DTLS,

DTLS is one choice, defined in RFC 7252.  Newer constrained implementation often look at OSCORE instead, RFC 8613.

> so you have to have DTLS. So again, I don’t see how this reduces complexity. It seems like it adds complexity.

I haven’t checked this, but I would expect there are enough differences in how DNSoDTLS uses DTLS that the complexity of getting this right exceeds that of using CoAP.

>> I’ll leave that to the authors; obviously, all caches have limitations, but being able to make use of CoAP caches along the way would be an improvement.
> 
> It is not a given that caching with CoAP makes things better. What is CoAP’s caching behavior? How will it handle short TTLs? Reading the document, it’s clear this has not been considered.

The -00 version does not have to solve those problems.  Slideware does exist for them...

> Given that the whole point of this is to make DNS connections private, I would assume that the cache shouldn’t have the credentials to peek into the packet. Except that it must. So I really don’t understand the threat model here.

OSCORE was designed to offer some capabilities in this regard.  I’m sure a future document will include examples for that.
But this is work that best can be done in the working group, between implementers and experts for the specific protocols and their caching behaviors.

>> That can definitely be done (for a definition of “compress” — a concise form for some DNS data might be a better approach), but it to me it seemed working out the protocol machinery first is the right way to proceed here.  (From the point of view of the CoAP protocol, this would just be a separate media type.)
> 
> I don’t think this is true. Just because you can do something doesn’t mean you should. Until we can come up with some use case for this that solves a problem that isn’t already solved, I don’t think the IETF should be pursuing this work at all.

It seems to me you are basing this view on a scan of the individual submission document.
WG discussions have happened (and many WG members are also cognizant of, e.g., CoAP caching behavior), so it is not a surprise that many of use come to a different conclusion.

Grüße, Carsten