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

Ted Lemon <mellon@fugue.com> Thu, 18 August 2022 13:28 UTC

Return-Path: <mellon@fugue.com>
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 B6ED9C14F734 for <dns-privacy@ietfa.amsl.com>; Thu, 18 Aug 2022 06:28:23 -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, RCVD_IN_DNSWL_HI=-5, 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=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 3KHl5QhNHFsF for <dns-privacy@ietfa.amsl.com>; Thu, 18 Aug 2022 06:28:20 -0700 (PDT)
Received: from mail-oa1-x2f.google.com (mail-oa1-x2f.google.com [IPv6:2001:4860:4864:20::2f]) (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 210D0C1526FB for <dns-privacy@ietf.org>; Thu, 18 Aug 2022 06:28:19 -0700 (PDT)
Received: by mail-oa1-x2f.google.com with SMTP id 586e51a60fabf-11ba6e79dd1so1737000fac.12 for <dns-privacy@ietf.org>; Thu, 18 Aug 2022 06:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=+flOFIqivjQVoJ2F1W1YKJ1H9BdccGGZbFuYQVAeguw=; b=XcF8GIdKCveuUNzc298Bd5UzBLUEab53Kax1XiIclEriqrH2MBtpV3NEFtDPbH/Hhd OJ/UGxSK5e2HjKK58EXiejETBkRf2c4Y2KhK/9meKPVHGSiY1DuWNOwmDWSFRjju+b9X kHfOI69eFayJZUKEBqQqCd15x2lhC33NoWq9o1CxNiuFrwHVTvcKlRCpLA4qBck+cwkc UvaN1Q8QMhcBT33BTdsIOTahysPCBiYJxO9HhzpkbvQ5WysZ/pabcSC8Mi3+8JryiJMb h3EKrYN9+kDx9q6FmQnqHGbZP49ENTrWde8rps8UvLFfocusgTdgofLn4P15QRj7nOZ2 cH3A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=+flOFIqivjQVoJ2F1W1YKJ1H9BdccGGZbFuYQVAeguw=; b=jjOpGgbf02sJvA1rPQmTgdCFOITqs89iHFD+9u+wTkpCmxOdU/G40SKk7nCUePN2H3 AwgRG3oyu9NSo4OYjYVepk9b/pf7nRekq89xLg/Zw0LsaREwhGY9DhJVOtuWN2KdmeQN SrLng24lBJKbGiUid1JpsR5Xg3/J0e39no9fSI78fQUwIOTmKtHb460woU4qPHg3Rg2G MptFxKDrM6BuB7tW/uufmoch2nYlGfVSSLZLz4PYvx8dhwu6HWJ5ImHqsDcMGHx96rfA +ZpyP6UwU3BP9poGq1icJlq16Qwr/gjrwbay+IB7zMNDkyaFJdyjTIbenLzr3JOm6+mU 9QVA==
X-Gm-Message-State: ACgBeo2oBIBAxHvnPs7xSJIBvzRxbLpnp+LszqzzxonKRw1FaX6TQ3BZ 8jVNtf31XElj6W4kZ0pYPlS8mDrWPtbv8VYq/SHu8uR1q60=
X-Google-Smtp-Source: AA6agR5AuQrVhccGsSGfPcq8vOFctZgv2a0CSzQK3KQkUEygxQ7flWrtZBxQh0XaCd4SDg2qRzLPRIYMn6E1Jz03LHE=
X-Received: by 2002:a05:6870:45a9:b0:10a:9ebc:63ab with SMTP id y41-20020a05687045a900b0010a9ebc63abmr1324061oao.209.1660829298561; Thu, 18 Aug 2022 06:28:18 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <26b55a44-1d79-0874-afbe-7d43bd1b39d2@fu-berlin.de>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 18 Aug 2022 09:27:43 -0400
Message-ID: <CAPt1N1nPEfJL_5_smq6Un92BRCTQxtYO0krjx58N8KS2qVj5xQ@mail.gmail.com>
To: Martine Sophie Lenders <m.lenders@fu-berlin.de>
Cc: Carsten Bormann <cabo@tzi.org>, Tim Wicinski <tjw.ietf@gmail.com>, dns-privacy@ietf.org, dnsop@ietf.org, core@ietf.org
Content-Type: multipart/alternative; boundary="0000000000005faa4305e683f4cf"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/_pTGdixma56VLC-Cu4mHTlJq4Oc>
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: Thu, 18 Aug 2022 13:28:23 -0000

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> <mellon@fugue.com> wrote:
>
> On Aug 15, 2022, at 1:34 PM, Carsten Bormann <cabo@tzi.org> <cabo@tzi.org> wrote:
>
> On 15. Aug 2022, at 17:11, Ted Lemon <mellon@fugue.com> <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
>
> _______________________________________________
> core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core
>
>
>