Roman Danyliw has entered the following ballot position for draft-ietf-dnsop-structured-dns-error-24: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-structured-dns-error/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Questions around the use of clear-text DNS and EXTRA-TEXT: -- Section 5.3 1. If the integrity of the DNS response is not guaranteed, the DNS client MUST NOT act upon data in the EXTRA-TEXT field, as the data is vulnerable to modification by an on-path attacker. What provides an adequate guarantee of integrity to act upon the data? What happens if the stub resolver uses DOH, but the recursive resolver does not? -- Section 10.1, “This specification assumes the use of authenticated, integrity-protected DNS transports (e.g., DoT, DoH, or DoQ). Such transports MUST be based on TLS 1.3 [RFC8446] or later.” This seems ambiguous. Is “assuming the use of” the same thing as requiring the using of “authenticated, integrity-protected DNS transports” when the EXTRA-TEXT field is use? If so, please be explicit. I ask because a few sections later (Section 10.4 note below) the text is unambiguous on the need for “encrypted DNS transport”. -- (not DISCUSS feedback, here for reference) Section 10.4, “This specification requires the use of an encrypted DNS transport (e.g., DoT, DoH, or DoQ), which protects both the DNS query and the structured error response from passive observers.” This is unambiguous. Thanks. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you to Stewart Bryant for the GENART review. I support the DISCUSS position of Mike Bishop ** Section 1. Editorial. One of the other benefits of the approach described in this document is to eliminate the need to "spoof" block pages for HTTPS resources. This is achieved since clients implementing this approach would be able to display a meaningful error message, and would not need to connect to such a block page. This approach thus avoids the need to install a local root certificate authority on those IT-managed devices. Given that this section discusses multiple deployment environments (e.g., enterprise, home networks) and this paragraph ends with referencing only an “IT-managed” environment, would it be appropriate to make that clearer? OLD One of the other benefits of the approach described in this document is to eliminate the need to "spoof" block pages for HTTPS resources. NEW One of the other benefits of the approach described in this document is to eliminate the need to "spoof" block pages for HTTPS resources in enterprise environments. ** Section 3. Editorial. Each of these methods have advantages and disadvantages that are discussed below: As far as I can tell, only the disadvantages are listed in the 3 bullets under this text. I can’t find the advantages. ** Section 3 -- Bullet #1: Frustrated, the end user may switch to an alternate network that offers no DNS filtering against malware and phishing, potentially compromising both security and privacy. -- Bullet #2: Frustrated, the end user may resort to using insecure methods to reach the domain, potentially compromising both security and privacy. Can this threat be more precisely articulated? What is being described in bullet #1 and #2 seems like how web browsing looks in the real world. For example, I am a student on a mobile device using the school’s Wi-Fi network but it blocks the social media site I want to use, so I switch to the cellular network. I am employee on a restricted enterprise Wi-Fi network with a BYOD situation, but it blocks the shopping site where I want to make a purchase while having lunch in the cafeteria, so I switch to the cellular network. I try to access a web-site but it blocks me due to geofencing policies so I use a VPN to exit in a different geography. This speaks nothing of users in places with censoring regimes implemented by carriers which regularly resort to alternative means of access. ** Section 3 To eliminate the need for an end user to click through certificate errors, an end user may manually install a local root certificate on a host device. Doing so, however, is also a bad security practice as it creates a security vulnerability that may be exploited by a MITM attack. What is the vulnerability being exposed? Isn’t the device serving back this warning the enterprise’s own infrastructure? Isn’t the local root certificate from the enterprise or associated service provider? ** Section 4 j: (justification) 'UTF-8'-encoded [RFC5198] human-readable explanation for the DNS filtering decision. … Returning non-UTF-8 data, syntactically invalid content, or deliberately meaningless values (including empty strings) indicates that a DNS server is misbehaving. If this is human readable explanation not meant for automated processing, what is a “deliberately meaningless value”? _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
