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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > > > 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 > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
