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

Alexander Mayrhofer <alexander.mayrhofer@nic.at> Mon, 12 September 2022 06:08 UTC

Return-Path: <alexander.mayrhofer@nic.at>
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 B6249C152592 for <dns-privacy@ietfa.amsl.com>; Sun, 11 Sep 2022 23:08:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nic.at
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 Z1ICyxfZgHoq for <dns-privacy@ietfa.amsl.com>; Sun, 11 Sep 2022 23:08:51 -0700 (PDT)
Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) (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 5A15BC1522C3 for <dns-privacy@ietf.org>; Sun, 11 Sep 2022 23:08:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nic.at; s=it2019; h=From:From:To:CC:Subject:Date:Message-Id:Content-Type:Received:Received:Received; bh=IKqhpyqQxb2SpJUqreUev/N9x2s4jJimjM4+hn7l2E8=; b=nC7+7UceDCsVI1mM5lIAwrHgeSSwagisQXzLFYB5uuNCNnkz4qHwaw2sZwp4MYZvsZhU1wvptiWk+O0Yv60RN+G4IDYofjAhnlcOWPGr7HNlv1FqVKw8r5pINWtbwjyA4v1lF4T9iUIloT8pLvMcuu40lWKoqhpwbtbU+t1utFS0Jziu5rja8rKPWaQteN061b1ESm5wWPesm8CVPOcz2HgkKRVD0ej1ZjSNJls839CXRAR3FCjWzSv+yOqK7a9jyRx+lYN1W3e12RA5+ds4DpEsgHHnRAaicUdrPO2KzziLqOV9Nhj+Vjidy1HLPHKAix0t+wUQGe4x/CCPOTlTAA==;
Received: from nics-exch3.sbg.nic.at ([10.17.175.2]) by mail.sbg.nic.at over TLS secured channel (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) with XWall v3.56 ; Mon, 12 Sep 2022 08:08:46 +0200
Received: from nics-exch3.sbg.nic.at (10.17.175.2) by nics-exch3.sbg.nic.at (10.17.175.2) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.12; Mon, 12 Sep 2022 08:08:45 +0200
Received: from nics-exch3.sbg.nic.at ([fe80::3079:e311:a6d4:792b]) by nics-exch3.sbg.nic.at ([fe80::3079:e311:a6d4:792b%2]) with mapi id 15.01.2507.012; Mon, 12 Sep 2022 08:08:45 +0200
Thread-Topic: [dns-privacy] [DNSOP] [core] WGA call for draft-lenders-dns-over-coap
Thread-Index: AQHYwgJfsf5o3v1Exk+HOAqhY76y463XKA2AgAQuTHA=
References: <eb776071-e99c-93a9-b0ba-c14ad5c11e13@fastmail.com> <98cb0b90-4b23-257b-9553-7b0ef3a9bcab@fastmail.com> <CAHbrMsA4CnFKAxNXEvXfXGNgHi7FNt=T+pPMOca13bBCxi12Gg@mail.gmail.com> <0597f734-d900-4eb0-9004-134d318e619c@nic.cz>
In-Reply-To: <0597f734-d900-4eb0-9004-134d318e619c@nic.cz>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.10.0.223]
From: Alexander Mayrhofer <alexander.mayrhofer@nic.at>
To: =?utf-8?B?VmxhZGltw61yIMSMdW7DoXQ=?= <vladimir.cunat=2Bietf=40nic.cz@dmarc.ietf.org> , Ben Schwartz <bemasc@google.com>
Cc: "core@ietf.org" <core@ietf.org> , DNS Privacy Working Group <dns-privacy@ietf.org> , dnsop <dnsop@ietf.org> , =?utf-8?B?SmFpbWUgSmltw6luZXo=?= <jaime@iki.fi>
Date: Mon, 12 Sep 2022 08:08:45 +0200
X-Assembled-By: XWall v3.56
Message-ID: <bc9fc50dc9a1494c88466789978f29aa@nic.at>
X-XWALL-BCKS: auto
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="_NextPart_1_5wzusth2OtpFjSLShuyKOILxweH"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/RGJUs9dM_PKzZIMK5MnJv-Oew6U>
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: Mon, 12 Sep 2022 06:08:55 -0000

Hello everyone,

Speking as the author of RFC 7830 – there was some discussion whether the document should say “SHOULD NOT” or “MUST NOT” when padding DNS packets over unencrypted packets. We couldn’t come up with any other use case (maybe except testing of the feature over unencrypted transport), so the consensus of the group was that we should be strict, especially as padding might be an easy way to bloat packets. I do agree that this connects DNS answer behaviour with transport choice – hence creates a dependency that’s probably not very wise in a protocol that has already pretty complex dependencies.

If the community believes that this requirement should be relaxed (and it’s worth the effort), I’m up for creating a revision of RFC 7830. This might also be a chance to step up EDNS Padding to Internet Standard – I think it’s widely deployed on billions of devices (Android..).

Thoughts?

Best,
Alex


Von: dns-privacy <dns-privacy-bounces@ietf.org> Im Auftrag von Vladimír Cunát
Gesendet: Freitag, 9. September 2022 18:11
An: Ben Schwartz <bemasc@google.com>
Cc: core@ietf.org; DNS Privacy Working Group <dns-privacy@ietf.org>; dnsop <dnsop@ietf.org>; Jaime Jiménez <jaime@iki.fi>
Betreff: Re: [dns-privacy] [DNSOP] [core] WGA call for draft-lenders-dns-over-coap

On 06/09/2022 17.06, Ben Schwartz wrote:
The choice of transport is independent of the DNS server's answering behavior, which must not be modified by the transport.

Nit: there's a very specific counter-example of EDNS padding which is meant to be added depending on transport encryption.  https://www.rfc-editor.org/rfc/rfc7830#section-6

There might be some others (in future, too), as encryption does change some considerations, but yes - not basic stuff like following CNAMEs.

--Vladimir | knot-resolver.cz