Re: [dns-privacy] [core] WGA call for draft-lenders-dns-over-coap
Matthias Waehlisch <m.waehlisch@fu-berlin.de> Wed, 24 August 2022 09:33 UTC
Return-Path: <waehl@zedat.fu-berlin.de>
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 BCF2AC1524A0; Wed, 24 Aug 2022 02:33:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.904
X-Spam-Level:
X-Spam-Status: No, score=-6.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] 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 D0y_-6mwgvb2; Wed, 24 Aug 2022 02:33:03 -0700 (PDT)
Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) (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 A9ED7C14F742; Wed, 24 Aug 2022 02:33:02 -0700 (PDT)
Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.95) with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (envelope-from <waehl@zedat.fu-berlin.de>) id 1oQmks-0039DO-AI; Wed, 24 Aug 2022 11:32:58 +0200
Received: from 87-77-187-23.mna.fu-berlin.de ([87.77.187.23] helo=mw-x1.zedat.fu-berlin.de) by inpost2.zedat.fu-berlin.de (Exim 4.95) with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (envelope-from <m.waehlisch@fu-berlin.de>) id 1oQmks-000NBF-4h; Wed, 24 Aug 2022 11:32:58 +0200
Date: Wed, 24 Aug 2022 11:32:57 +0200
From: Matthias Waehlisch <m.waehlisch@fu-berlin.de>
To: Ted Lemon <mellon@fugue.com>
cc: Martine Sophie Lenders <m.lenders@fu-berlin.de>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop@ietf.org, dns-privacy@ietf.org, core@ietf.org
In-Reply-To: <CAPt1N1nPEfJL_5_smq6Un92BRCTQxtYO0krjx58N8KS2qVj5xQ@mail.gmail.com>
Message-ID: <alpine.WNT.2.00.2208241129320.33552@mw-x1>
References: <693CE6A0-9479-4265-B3D9-ADEF9EF4B959@tzi.org> <519510F7-032C-4BCE-AD7E-6889ABC7991D@fugue.com> <EF2A3A25-4D89-4258-9CE0-0FC9F8CC2080@tzi.org> <26b55a44-1d79-0874-afbe-7d43bd1b39d2@fu-berlin.de> <CAPt1N1nPEfJL_5_smq6Un92BRCTQxtYO0krjx58N8KS2qVj5xQ@mail.gmail.com>
User-Agent: Alpine 2.00 (WNT 1167 2008-08-23)
X-X-Sender: waehl@mail.zedat.fu-berlin.de
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="254009-10449-1661333474=:33552"
Content-ID: <alpine.WNT.2.00.2208241131230.33552@mw-x1>
X-Original-Sender: m.waehlisch@fu-berlin.de
X-Originating-IP: 87.77.187.23
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/F_kaQ5kiI7nEs5fvrMU2upKOfgY>
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: Wed, 24 Aug 2022 09:33:07 -0000
Hi Ted, sorry for the late reply! re scenarios: during bootstrappign, a constrained requires CoAP and DNS client capablities. for example, when an LwM2M client registers at a LwM2M server, which acts as a partial CoAP Resource Directory. re: your statement "The privacy benefit of DoH wouldn't apply on a Thread network—you're hiding things that are easily discovered, and snooping is expensive, so constrained devices aren't likely to do it." i don't see why an attacker necessarily needs to use a constrained device. can you elaborate on who is "we" in your arugmentation? thanks matthias On Thu, 18 Aug 2022, Ted Lemon wrote: > Before you go down the mDNS-over-constrained-networks rabbit hole, you might want > to look at existing practice. E.g. Thread uses SRP (draft-ietf-dnssd-srp, in last > call) for service registration, and then uses regular DNS and DNS Push for lookups. > mDNS is used on the infrastructure link (e.g. WiFi) because it's ubiquitous and > permissionless, although it would be nice to get to where we could use DNS Push > there as well. The primary argument against mDNS for constrained networks and > devices is that it winds up delivering a lot of badput: nearly every mDNS packet is > useless for nearly every recipient. This isn't a problem for unconstrained networks > and unconstrained devices, but you don't want a battery operated device to have to > turn on its receiver and look at every service discovery packet, and possibly have > to forward it, when nearly all of them are not going to be of interest. > I think your main value-add here is compactness. Your argument for OSCORE sounds > convincing, but I'd like to see some practical application of this. If you are > thinking about how to do compression, why wait to write that draft? To me it seems > like a pretty clear sine qua non for the draft you're trying to work on first. To > put this in perspective, in the Thread work we've definitely considered ways to > compress DNS packets. We haven't done it, because it's not strictly necessary, but > this would certainly be an attractive thing to consider. Whereas the other stuff > you are doing here would not be at all compelling. We wouldn't be interested in > this caching mechanism, for example. Message privacy isn't very interesting, since > our primary use for DNS is DNS service discovery, and our secondary use is > basically also service discovery—finding the IP address of a cloud service with a > known name. The compelling use case for DoH is the ability to make HTTPS and DNS > lookups share fate; there's no similar compelling use case here. The privacy > benefit of DoH wouldn't apply on a Thread network—you're hiding things that are > easily discovered, and snooping is expensive, so constrained devices aren't likely > to do it. > > There may be a privacy story here, but I think if there is it needs to be > articulated, and not just assumed. > > On Thu, Aug 18, 2022 at 3:40 AM Martine Sophie Lenders <m.lenders@fu-berlin.de> > wrote: > Hi! > > Martine Lenders, here, one of the co-authors of the draft. > > Indeed, as Carsten already stated: Using OSCORE is one of our main use > cases, using a compressed format for DNS messages is another. > > We implemented both DNS over DTLS and DNS over CoAP (DoC), including > the variants DNS over CoAPS and DNS over OSCORE, for our evaluation of > DoC [1]. It shows DNS over OSCORE to be in advantage compared to both > DNS over DTLS or DNS over CoAPS. Yes, compared to DNS over DTLS it adds > complexity, at least upfront, but it can be assumed that CoAP/OSCORE is > already present for the application. This amortizes this disadvantage > to only the construction and parsing of DNS messages. With DNS over > DTLS (assuming we even use transport encryption with CoAP) we still > need to implement the state machine of DNS over DTLS, in addition to > DNS message handling. On the other hand side, we gain additional > advantages from the CoAP feature set when using DoC, such as block-wise > transfer and, as previously discussed, en route caching. The latter > would also become possible in an end-to-end encrypted way with [2]. > Some of these advantages are mentioned in Section 1 of the draft. > > For a compressed message format, we plan to provide a separate draft in > the future, in an attempt to keep things simple and to easily make that > content type also usable, e.g., with DoH. > > Another use case is the usage of encrypted DNS over Low-Power WANs, > e.g., LoRaWAN. Here, due to the transport encryption with DTLS, > compression to fit the small PDUs and handle the low data rates [3], is > not straightforward. As OSCORE encrypts on the application layer, > however, we are able to compress most of the surrounding metadata away > [4], and purely transport the encrypted payload. > > Lastly, another possible use cases, which we did not evaluate in any > way yet, would be an encrypted version of mDNS and thus DNS-SD, > utilizing OSCORE group communication [5]. Multicast encryption is not > covered by either of the other encrypted DNS-over-X solutions so far. > > Best regards > Martine > > [1] https://arxiv.org/pdf/2207.07486.pdf > [2] https://datatracker.ietf.org/doc/draft-amsuess-core-cachable-oscore > [3] https://datatracker.ietf.org/doc/rfc8724 > [4] https://datatracker.ietf.org/doc/rfc8824 > [5] https://datatracker.ietf.org/doc/draft-ietf-core-oscore-groupcomm > > Am 15.08.22 um 20:09 schrieb Carsten Bormann: > > 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 i > s for DNS-over-CoAP before proceeding with this, > > The main use case is systems that already implement CoAP and do not want to add mac > hinery 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 lo > ok at OSCORE instead, RFC 8613. > > so you have to have DTLS. So again, I don’t see how this reduces complexity. It see > ms like it adds complexity. > > I haven’t checked this, but I would expect there are enough differences in how DNSo > DTLS 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 a > ble 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 cachin > g behavior? How will it handle short TTLs? Reading the document, it’s clear this ha > s not been considered. > > The -00 version does not have to solve those problems. Slideware does exist for th > em... > > Given that the whole point of this is to make DNS connections private, I would assu > me that the cache shouldn’t have the credentials to peek into the packet. Except th > at 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 d > ocument will include examples for that. > But this is work that best can be done in the working group, between implementers a > nd experts for the specific protocols and their caching behaviors. > > That can definitely be done (for a definition of “compress” — a concise form for so > me DNS data might be a better approach), but it to me it seemed working out the pro > tocol 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 shou > ld. 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 docu > ment. > 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 co > nclusion. > > Grüße, Carsten > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core > > > > -- Matthias Waehlisch . Freie Universitaet Berlin, Computer Science .. http://www.cs.fu-berlin.de/~waehl
- [dns-privacy] WGA call for draft-lenders-dns-over… Jaime Jiménez
- Re: [dns-privacy] [core] WGA call for draft-lende… Jaime Jiménez
- Re: [dns-privacy] [core] WGA call for draft-lende… Tim Wicinski
- Re: [dns-privacy] [core] WGA call for draft-lende… Ted Lemon
- Re: [dns-privacy] [core] WGA call for draft-lende… Carsten Bormann
- Re: [dns-privacy] [core] WGA call for draft-lende… Ted Lemon
- Re: [dns-privacy] [core] WGA call for draft-lende… Carsten Bormann
- Re: [dns-privacy] [core] WGA call for draft-lende… Martine Sophie Lenders
- Re: [dns-privacy] [core] WGA call for draft-lende… Ted Lemon
- Re: [dns-privacy] [core] WGA call for draft-lende… Matthias Waehlisch
- Re: [dns-privacy] [core] WGA call for draft-lende… Jaime Jiménez
- Re: [dns-privacy] [core] WGA call for draft-lende… Jaime Jiménez
- Re: [dns-privacy] [DNSOP] [core] WGA call for dra… Ben Schwartz
- Re: [dns-privacy] [DNSOP] [core] WGA call for dra… Vladimír Čunát
- Re: [dns-privacy] [DNSOP] [core] WGA call for dra… Alexander Mayrhofer
- Re: [dns-privacy] [core] [DNSOP] WGA call for dra… Martine Sophie Lenders
- Re: [dns-privacy] [core] [DNSOP] WGA call for dra… Ben Schwartz
- Re: [dns-privacy] [core] [DNSOP] WGA call for dra… Carsten Bormann
- Re: [dns-privacy] [core] [DNSOP] WGA call for dra… Martine Sophie Lenders
- Re: [dns-privacy] [DNSOP] [core] WGA call for dra… Ben Schwartz
- Re: [dns-privacy] [DNSOP] [core] WGA call for dra… Martine Sophie Lenders
- Re: [dns-privacy] [DNSOP] [core] WGA call for dra… Ben Schwartz
- [dns-privacy] draft-ietf-core-dns-over-coap-01 (w… Martine Sophie Lenders