IETF Logo Mail Archive

Re: [core] [dns-privacy] [DNSOP] 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: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6A6C152592 for <core@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.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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_DNSWL_BLOCKED=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 mDGGYbRVj4bq for <core@ietfa.amsl.com>; Sun, 11 Sep 2022 23:08:50 -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 2CD92C1522BE for <core@ietf.org>; Sun, 11 Sep 2022 23:08:49 -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=d//tAQZOeJLiGwWQsN/q0INTtqYSzpxTxSZ4Q62+k0k=; b=ThuOfskwNr7tzYUxZPxKC1prm+il6cyCkCLiqKJs9fnzh4zETna/3QyBHDRrj6mJlSP4ONU7IUAfdhBjsfIR+t3B2rgHkHbQgTrLZR6Bu3djjyB3ITUJVZXwArUvgrIVS3oW5fByzORrR+y6Jr9rlsf6GeWtOIFoOTO1A7hqP0w7Q0StJvSWiOdkPdiwqtorlhULTzmBuh/BTBK1o0aEsj/OvIhJ+W/O/D1NeCEyHnffU+jTKrnW9fzINZ12hd69oIvBysAXRlXxcRZ6MVQ7/5pA1cfhNmyg0xZcVP6bMXaW2uAGFPOn7gwSp3HimdV2LmBiH0zCJ3p0hxGHuYM2zg==;
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: Vladimír Čunát <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>, Jaime Jiménez <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_5wzustgywpXqvhnzWgDeWWCquOK"
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/OOPdUPKJypkIJUTBkT5EwdRl6-o>
Subject: Re: [core] [dns-privacy] [DNSOP] WGA call for draft-lenders-dns-over-coap
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-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

v2.23.0 | Report a Bug | By Email