Re: [dns-privacy] [Technical Errata Reported] RFC9250 (7883)

Sara Dickinson <sara@sinodun.com> Fri, 05 April 2024 16:27 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 DE278C16942F for <dns-privacy@ietfa.amsl.com>; Fri, 5 Apr 2024 09:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.397
X-Spam-Level:
X-Spam-Status: No, score=-4.397 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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, 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=sinodun.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 BzWiQdkzND60 for <dns-privacy@ietfa.amsl.com>; Fri, 5 Apr 2024 09:27:10 -0700 (PDT)
Received: from mx1.mythic-beasts.com (mx1.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310B8C151984 for <dns-privacy@ietf.org>; Fri, 5 Apr 2024 09:27:09 -0700 (PDT)
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=Vd2Ex7hbdkEp5ut0nbjydZ12E+spcKV5CJ1gGrTrXo8=; b=X1bkF3kEpWVT/FJ+hvEhXB30jK wnjjZ6s3mIM37hgLvC7moYuxDhXCpxVy05y9s48uZu5+Gt5Hf7efdwDAumOsQJM0qA/vA/bJ7GKaP Y71UBHS0OcaxzrDnFO4M/+ZhejxTWUpp7fAaQsXZ8MY9RhWCHcFJqmDo4m8bjtlIJN5thKO2avyQD UADh7kk8ImZj8b/mzTPGgswWFBdVpqpdw1zQkXha1lfxtL9HXXwfFZl/P4WaaU45YyrB2QI2d/ocO AdEytCAQmnkAosSwI/M/VenAx/4Uu9y5ZFC0rqqYPjnLqQzQWOKhuNfqD8DokSP4ROjaL+7OIkz0H ZbnG9GCQ==;
Received: by mailhub-cam-d.mythic-beasts.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from <sara@sinodun.com>) id 1rsmP3-00D1Pk-4g; Fri, 05 Apr 2024 17:26:57 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
From: Sara Dickinson <sara@sinodun.com>
In-Reply-To: <20240405013857.7736ACE3DB@rfcpa.amsl.com>
Date: Fri, 05 Apr 2024 17:26:45 +0100
Cc: Christian Huitema <huitema@huitema.net>, allison.mankin@gmail.com, ek.ietf@gmail.com, evyncke@cisco.com, brian@innovationslab.net, tjw.ietf@gmail.com, lyra@omg.lol, dns-privacy@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <219E0363-AE24-43F1-8829-9562524954B5@sinodun.com>
References: <20240405013857.7736ACE3DB@rfcpa.amsl.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>
X-Mailer: Apple Mail (2.3696.120.41.1.8)
X-BlackCat-Spam-Score: 19
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/c6xX8ZrhD5nY-91hnp9yCTj8EMo>
Subject: Re: [dns-privacy] [Technical Errata Reported] RFC9250 (7883)
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: Fri, 05 Apr 2024 16:27:14 -0000

I agree with the errata - I believe this was an oversight in this PR:
https://github.com/huitema/dnsoquic/pull/132/files that was created in response to review from the WG

- it changed SHOULD -> MUST in section 5.4 but
- it did not update the SHOULD in section 7.5 to be consistent at the same time.

I don’t see any discussion about this mismatch on the mailing list although I may have missed it (I only see support that padding was a MUST) - I think it just went unnoticed. However since the two sections reference each other, and only each other, then I agree they should be consistent as the errata proposes.

Sara.


> On 5 Apr 2024, at 02:38, RFC Errata System <rfc-editor@rfc-editor.org> wrote:
> 
> The following errata report has been submitted for RFC9250,
> "DNS over Dedicated QUIC Connections".
> 
> --------------------------------------
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7883
> 
> --------------------------------------
> Type: Technical
> Reported by: Lyra Naeseth <lyra@omg.lol>
> 
> Section: 7.5
> 
> Original Text
> -------------
> Implementations SHOULD use the mechanisms defined in Section 5.4 to
> mitigate this attack.
> 
> Corrected Text
> --------------
> Implementations MUST use the padding mechanisms defined in Section 5.4
> to mitigate this attack.
> 
> Notes
> -----
> Section 5.4 states that "[i]mplementations MUST protect against the traffic analysis attacks described in Section 7.5", but Section 7.5 describes that obligation as a "SHOULD". "MUST" is correct, and the inconsistent "SHOULD" in Section 7.5 is an error.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --------------------------------------
> RFC9250 (draft-ietf-dprive-dnsoquic-12)
> --------------------------------------
> Title               : DNS over Dedicated QUIC Connections
> Publication Date    : May 2022
> Author(s)           : C. Huitema, S. Dickinson, A. Mankin
> Category            : PROPOSED STANDARD
> Source              : DNS PRIVate Exchange
> Stream              : IETF
> Verifying Party     : IESG