Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsoquic-07.txt

Sara Dickinson <sara@sinodun.com> Tue, 04 January 2022 17:00 UTC

Return-Path: <sara@sinodun.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 7D9D33A1E63 for <dns-privacy@ietfa.amsl.com>; Tue, 4 Jan 2022 09:00:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMHrIo6QG7C3 for <dns-privacy@ietfa.amsl.com>; Tue, 4 Jan 2022 08:59:55 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489B73A1E5F for <dns-privacy@ietf.org>; Tue, 4 Jan 2022 08:59:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=1E9hi4MucTTiWJnCxLUazsT9f5DsvZPIeN72KRzZlEQ=; b=olYnmoupGd96ust18ipN9ir1sK aGgpFo8DU1F8NgdWWtfu5iHsr+oAwTmqYLecT/kL4YhMyETIWUvH+6M2haczrEP2403KYc3tS6UHW 65wnwzn0+owfa/QuwGwnK3WAHknBFIAWrFrJHO8ZU8heDjJYCldosuKsZ5uK7+BEl1EL7ylLOAlrM elKT8J6aW02o4wVVZnFKgrkbmWvh1ec6K+StInystVgY8+rKI+/Oz6FuKWc5LjAcM+t6phJSkk6W5 7+5fjgVYePUI3+ERTZxd0oj9b0QUyDrr3SFsgC7TD9iyH7BYG3NeaGYNd8Klfj/kHgqRY6ln6fnDo IFbLTpZg==;
Received: from [62.3.64.153] (port=13375 helo=[192.168.12.101]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <sara@sinodun.com>) id 1n4nA7-0008Pw-AD; Tue, 04 Jan 2022 16:59:51 +0000
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <CAHXf=0qQk2zK9_wihfXcnScU9D7oCO5g_quCitGceRszt9HrMQ@mail.gmail.com>
Date: Tue, 04 Jan 2022 16:59:43 +0000
Cc: DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E7F70B0A-82DC-43BA-BF02-2AB20362D1C7@sinodun.com>
References: <163837452936.12358.1396647661232168093@ietfa.amsl.com> <CAHXf=0qQk2zK9_wihfXcnScU9D7oCO5g_quCitGceRszt9HrMQ@mail.gmail.com>
To: Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
X-BlackCat-Spam-Score: 4
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/XPUpR4QJKKxTL2BehDpWVLMyxNY>
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsoquic-07.txt
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 04 Jan 2022 17:00:01 -0000


> On 9 Dec 2021, at 09:25, Alexander Mayrhofer <alex.mayrhofer.ietf@gmail.com> wrote:
> 
> Sara, Allison, Christian,
> 
> I read through the latest revision of DoQ, and i'm afraid i do have a
> comment regarding the padding section. More specifically, i think the
> second "option" of section 6.4 should refer to the base specification
> of EDNS0-Padding, rather than the Padding policies RFC. It currently
> reads as:
> 
>   *  if padding at the QUIC level is not available or not used, DNS
>      over QUIC MUST ensure that all DNS queries and responses are
>      padded to a small set of fixed sizes, using the EDNS padding
>      extension as specified in "Padding Policies for Extension
>      Mechanisms for DNS (EDNS(0))" [RFC8467].
> 
> And i do believe that - as the sentence stands - the reference should
> be RFC 7830. Note that RFC 8467 is Experimental (and was by intent, as
> the privacy properties of Padding would probably shift with more
> operational expertise). So, i feel REQUIRING that padding is used
> makes more sense than REQUIRING the use of the experimental padding
> sizes in RFC8467.
> 
> I think the sentence should read "padded to a small set of fixed
> sizes, using the EDNS Padding Extension as specified in [RFC7830]."
> 
> I like the "aligned with..." text in the previous bullet point, which
> could also be used here, indicating that the MUST is for the the
> padding, and not necessarily for that revision of the padding policy.

Hi Alex, 

Sorry for slow response and many thanks for spotting this mistake. I agree that the second bullet should reference RFC7830 and so propose the following update:

   *  if padding at the QUIC level is not available or not used, DNS
      over QUIC MUST ensure that all DNS queries and responses are
      padded to a small set of fixed sizes, using the EDNS padding
      extension as specified in [RFC7830].  The sizes SHOULD be aligned
      with the recommendations of the "Padding Policies for Extension
      Mechanisms for DNS (EDNS(0))" [RFC8467].


Re-reading the whole section, I also noticed an inconsistency. The first sentence is only a SHOULD at the moment:

“ Implementations SHOULD protect against the traffic analysis attacks
   described in Section 9.5 by the judicious injection of padding. “

but given the second bullet is a MUST, I think this is also actually a MUST. 

I’ve created a PR with both these changes for review:
https://github.com/huitema/dnsoquic/pull/132

Regards

Sara.