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

[Allison Mankin <[e-mail]>]

I agrée with Sara and I think even if we had some reason for the
inconsistency in the past, making both sections say MUST and be consistent
is appropriate.

On Fri, Apr 5, 2024 at 12:27 Sara Dickinson <[e-mail]> wrote:

> 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 <[e-mail]>
> 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 <[e-mail]>
> >
> > 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
>
>