Hi Mark, Thanks for the detailed review. please see inline
On Tue, 22 Jul 2025 at 23:04, Mark Nottingham <mnot= [email protected]> wrote: > Hi all, > > After the discussion on Monday, I had a look through > structured-dns-error-15 to see if anything would clash with what we're > thinking of in draft-nottingham-public-resolver-errors. > > In short, it appears that updates by the authors address many of the > issues I found previously; there are only a couple left that would raise > concerns for me if the two drafts were kept separate. See below for those, > along with some comments and questions I had along the way (that don't > affect that decision). > > ## Issues > > - 5.2 prohibits using sub-error codes in 'Censored' responses. That seems > excessive; conceivably, they might conceivably be needed down the road. > Yes, updated section 5.2 to clarify that sub-error codes for 'Censored' can be added in future specifications. > > - Section 5.3 step 2 requires the use of encrypted DNS, otherwise the > extra information is thrown away. Conceivably, some clients may have enough > information available to trust non-encrypted DNS at some future time. I > agree with the notion that the client should evaluate the context of the > DNS resolver and make decisions based upon that regarding how to use the > information -- and that definitely involves whether the connection is > encrypted -- but baking it into the algorithm like this precludes them from > any future flexibility, no matter what the use case. > > If WG consensus on this is firm and fully informed, so be it, but I > thought I heard an indication that there was a subtle shift away from such > draconian measures in the discussion on Monday. > - Similarly, 5.3 step 6 puts constraints on the information available to > clients who have enabled a DoT opportunistic privacy profile. This likewise > seems to take any discretion out of the client's hands and bakes it into > the algorithm. > > - Same question for step 7 regarding opportunistic discovery. > The reason for this strict requirement is that DNSSEC does not protect the EDE option. If we allow the EXTRA-TEXT field to be processed over plaintext, an on-path attacker can inject EDE. Without transport encryption, there is no way to verify that the structured error actually came from the resolver. > > - 10.2 puts specific requirements on browsers (as opposed to clients) -- > is that intentional? No, it is applicable to any DNS client including browsers. Fixed text. > > > > ## Comments > > - Section 3 ("DNS Filtering Techniques and Their Limitations") should be > moved to an appendix; it has a very different character as compared to the > rest of the specification. > Section 3 provides the problem statement for this work. It is necessary to explain why current filtering techniques are insufficient before defining the new solution. > > - Because this specification requires use of I-JSON, it should be > clarified whether non-conforming messages are required to be rejected. See > RFC7493 Section 3. I'd suggest this NOT be required (but we still need to > be explicit about that). > Thanks, I will fix the text in the next revision. > > - Making 'j' mandatory seems excessive; most of these responses will never > be seen by "IT staff" and the justification may be self-evident from other > fields. > > - Requiring contact details for reporting seems... optimistic, and will > likely lead to 'do-not-reply' style addresses being used. I'd suggest > making this a SHOULD. > "c" and "j" are optional in the new version. > > - 10.2 "The value consists solely of an organization name and does not > contain any additional free-form content such as instructions, URLs, or > messaging intended to influence the end-user behavior." Is this > implementable? The context seems to imply it can be done in an automated > fashion. > If the name cannot be verified through a registry or heuristic check, the client is expected to error on the side of caution and not display it. I will update the text. > > - 11.1 Has a registry column for 'mandatory'. It should be noted that new > mandatory extensions can't be introduced in a backwards-compatible way, and > so this should always be 'no' for extensions registered after the initial > RFC publication. > I agree. We will add a note to the IANA considerations stating that any extensions added after the initial RFC publication must be 'no' for mandatory to maintain backwards compatibility. > > - 11.2 Probably needs to say that contact URI schemes must be registered > URI schemes. > Yes, fixed. Cheers, -Tiru > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > DNSOP mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
