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

Ben Schwartz <bemasc@google.com> Wed, 21 September 2022 19:31 UTC

Return-Path: <bemasc@google.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 0EE72C152571 for <dns-privacy@ietfa.amsl.com>; Wed, 21 Sep 2022 12:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.607
X-Spam-Level:
X-Spam-Status: No, score=-17.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 G7VSnUg2K9pM for <dns-privacy@ietfa.amsl.com>; Wed, 21 Sep 2022 12:31:21 -0700 (PDT)
Received: from mail-vk1-xa33.google.com (mail-vk1-xa33.google.com [IPv6:2607:f8b0:4864:20::a33]) (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 0C402C1522DE for <dns-privacy@ietf.org>; Wed, 21 Sep 2022 12:31:21 -0700 (PDT)
Received: by mail-vk1-xa33.google.com with SMTP id b81so3761406vkf.1 for <dns-privacy@ietf.org>; Wed, 21 Sep 2022 12:31:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=AuHqZckyxspnnMCNHC6RsZ4rtfVopty9DoPdCW2X8tw=; b=Hc4c0OYW01EjiGVs6iDfBHZIPcCEnaEtsib4UNU/LGFGCNMC16v8rrdd+kuIBet7cz aUwkbMB4D0QD2VmbEAcmQYpUFFixWiwjgplnT1FNu7MhyqD8bnE1Qp0tmFPS9Usptahn C980C5k7fAovEkMLWaqvuDxjrm79bgwl8pv4CDooKNFzo77RyohmYOZvQqhLxyXaNef4 1eP1Z3xFk4LrEYsB9w4j2+GkjJZFe2abqbOx9ezfRX2/yXce0z7UK/6Nui53pwSwCK7n G8jwaS4tqH682p8tJT4ZhEHYTd9lh6n+7LT3tz/vkiuATDjVYrZIjY2+JeIg7xx56kqP iEZQ==
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:subject:date; bh=AuHqZckyxspnnMCNHC6RsZ4rtfVopty9DoPdCW2X8tw=; b=3+pPhsUy+nlTl4fOIGZoZt2o6ZpeW6ha4XXZdZAEgOM9kkEsSso9BfEY0ml3CPyzU7 GR7MNUk/31rA76/mNXngUoOfG/sNjPFSRPGprZCRc4cRNdQeSN1KLNUqaSZN66K+zUuz caWP4hapOrf7azTkrr+13+OMUx+lXCS8W8/Zugwnjh2KhpBrk3Pgn9eMsvWsV2TRbudf Hh8hKJ/vz7Hsm30DLAKSsT70Vi7DlwvWNMIXMTIibjXW/193VWPbcxebieY8EymWc4E2 AN9QfzLfWzDOLPRnpsV2NllE2cJqakzmxe/UxsL6dfpwGewGq12e4PmaiHVwwiOcgHQk ONEQ==
X-Gm-Message-State: ACrzQf0NfyZmdok49XzbQZiPVXEHRPE+3zt7nWhn1W9njPmi3G60/KsY /qMqWW69RvFV69Bosuv5tXPts54zaV2+aSnyS8kf0A==
X-Google-Smtp-Source: AMsMyM4v9A+hyvrBIc0CjUct+hYJSrMsEPusSUvbAeSMti4+NtG7YAkKrzRGtqauu0KQfE+DjwwdW9P2Got8zDBFZyQ=
X-Received: by 2002:a1f:6411:0:b0:3a3:c894:325f with SMTP id y17-20020a1f6411000000b003a3c894325fmr3867002vkb.21.1663788679719; Wed, 21 Sep 2022 12:31:19 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsCdGhzw1WOm19KopKgAD2akReq_e0MfQbSQxpgS1hBixg@mail.gmail.com> <F32209CA-4EE3-4774-BD0F-C20DA2204E31@tzi.org> <402da239-3dd1-afa3-93ee-4a1602caa2d4@fu-berlin.de>
In-Reply-To: <402da239-3dd1-afa3-93ee-4a1602caa2d4@fu-berlin.de>
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 21 Sep 2022 15:31:07 -0400
Message-ID: <CAHbrMsDjGgVQmiaEPNigsOnW3QogLDyCt8kaR96_VH1AapHzzA@mail.gmail.com>
To: Martine Sophie Lenders <m.lenders@fu-berlin.de>
Cc: Carsten Bormann <cabo@tzi.org>, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>, core@ietf.org, DNS Privacy Working Group <dns-privacy@ietf.org>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000043680905e934fd06"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/S91O11_uexY2LPydBIq9CMmzfzI>
Subject: Re: [dns-privacy] [DNSOP] [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, 21 Sep 2022 19:31:22 -0000

Preparing a separate document on compact DNS seems like a fine start to me.

On Wed, Sep 21, 2022 at 4:32 AM Martine Sophie Lenders <
m.lenders@fu-berlin.de> wrote:

> Hi Ben, Hi Carsten,
>
> thanks for your suggestions, Ben! It seems a good idea to clarify options
> for compactification of DNS messages in a separate document, since the
> compactification is indeed not bound to CoAP. We will prepare such a draft
> until the cut-off for IETF 115, so we can discuss whether we keep or remove
> Section 5.1 at the IETF meeting in London. Would that work for you?
>
> I tend to agree with Carsten. At least with the current wording (or the
> proposed), the restatements may lead to confusion, but some guidelines for
> the constrained use case should IMHO be part of the document, even if only
> in reference to the new document proposed.
>
> Best
> Martine
>
> Am 20.09.22 um 18:17 schrieb Carsten Bormann:
>
> I think we are falling into the restatement antipattern.
>
> This antipattern happens when documents restate mandates from their
> references, invariably creating confusion if this is just a restatement or
> actually new normative text that replaces or updates text from the
> dependency. Don’t do that.
>
> Examples can be put into their own section and clearly marked as such.
>
> Grüße, Carsten
>
> Sent from mobile, sorry for terse
>
> On 20. Sep 2022, at 17:12, Ben Schwartz
> <bemasc=40google.com@dmarc.ietf.org> <bemasc=40google.com@dmarc.ietf.org>
> wrote:
>
> 
> Martine,
>
> Thanks for the proposed updated text regarding CNAMEs.  I agree that it is
> an improvement, but I still think it would be better to omit entirely.  By
> writing that implementations SHOULD follow RFC 1034, you imply that they
> are permitted not to, which seems objectionable.  I think it would be much
> clearer to simply say that use of DoC does not alter the DNS message
> contents.
>
> I feel similarly about the Additional section.  If you think that it would
> be useful to deviate from ordinary practices regarding the Additional
> section, I think this should be in a separate draft on compact DNS
> responses, not coupled to DoC.  For example, such compactification might be
> even more relevant to UDP Do53 than to DoC.
>
> --Ben
>
> On Mon, Sep 19, 2022 at 7:30 AM Martine Sophie Lenders <
> m.lenders@fu-berlin.de> wrote:
>
>> Hi,
>>
>> Sorry for the late reply, I was away from any keyboard for the past two
>> weeks.
>>
>> I think there might be a misunderstanding regarding the CNAME behavior,
>> due to some poor wording in our draft: The CNAMEs should, of course, only
>> be resolved in such a way, if the queried record was an A or AAAA record.
>> This does not, to my understanding, contradict the behavior described for
>> CNAMEs in RFC 1034. We propose a different wording for the first sentence
>> in 5.1 to prevent such misunderstandings in the future:
>>
>>     In the case of CNAME records in a DNS response to an A or AAAA record
>> query, a DoC server SHOULD follow common DNS resolver behavior [RFC1034
>> <https://www.ietf.org/archive/id/draft-ietf-core-dns-over-coap-00.html#RFC1034>
>> ] by resolving a CNAME until the originally requested resource record
>> type is reached.
>>
>> Regarding the population of the additional section, we also follow
>> recommendations in RFC 1034, to only include records useful to the client.
>> We deem this particularly noteworthy when it comes to DNS, as from our
>> analysis of DNS traffic, responses can become quite large due to an
>> abundance of records in the Additional section. With the message size
>> constraints in LLNs, it might thus be necessary to prune the DNS message
>> for records actually useful to the querying DoC client.
>>
>> Lastly, mind, that, at least in our model for DoC, a DoC client does not
>> further distribute the information it gathered via DoC.
>>
>> Regards
>> Martine
>>
>> Am 06.09.22 um 17:06 schrieb Ben Schwartz:
>>
>> Some further notes on this draft.
>>
>> Section 5.1 says that a DoC server "SHOULD" follow CNAMEs.  This is a
>> misunderstanding of the nature of DNS transports.  DoC is a DNS transport,
>> like DoT and DoH.  The choice of transport is independent of the DNS
>> server's answering behavior, which must not be modified by the transport.
>> Indeed, DPRIVE is now chartered to enable the use of alternate transports
>> for recursive-to-authoritative queries for which CNAME following has
>> entirely different rules.  This is possible precisely because the choice of
>> transport does not alter the logical DNS contents.
>>
>> Section 5.1 also proposes that the population of the Additional section
>> might follow different logic when using DoC.
>>
>> Modifying the logical DNS behavior would create a wide range of exciting
>> and unpredictable compatibility issues when trying to use a new transport.
>> I urge the authors to delete Section 5.1, which would resolve this
>> problem.  The draft could instead note that the DNS queries and responses
>> are not modified when using DoC, except under private arrangement between
>> the client and server.
>>
>> On Fri, Sep 2, 2022 at 12:20 PM Jaime Jiménez <jaime@iki.fi> wrote:
>>
>>> Dear CoRE WG,
>>>
>>> Thanks to the authors and the reviewers that provided comments on the
>>> list for this draft. Given the in-room support and the list discussion
>>> during the WGA the chairs believe that there is sufficient support for the
>>> adoption of this document in CoRE.
>>>
>>> The authors are advised to resubmit the draft-core-dns-over-coap and to
>>> set up a document repo under the CoRE Github organization at
>>> https://github.com/core-wg
>>>
>>> BR,
>>>
>>> Jaime Jiménez on behalf of the CoRE chairs.
>>> 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 listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core
>>>
>>> --
>>> Jaime Jiménez
>>>
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>>>
>>
>> _______________________________________________
>> core mailing listcore@ietf.orghttps://www.ietf.org/mailman/listinfo/core
>>
>>
>>
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>