I am reviewing this draft. I like it, but I have three issues: 1) The draft fails to include a recommendation to "fallback to DNS over TLS" when messages are too big for DTLS and UDP. This fallback recommendation was pretty much the consensus that I heard in Yokohama. I understand that we could in the future get DTLS extensions for supporting large messages, but these are not ready yet, and in the mean-time falling back to TCP is a pretty well established strategy.
2) The draft does not describe the DPRIVE target deployment scenario, i.e. between the client and a configured recursive resolver. A number of statements about credentials, fallback, etc., would be much easier to understand if the draft acknowledged that scenario. 3) The text at the top of section 3. (DTLS session initiation, Polling and Discovery) describes a mechanism to avoid interference with capture portals or similar mechanisms, which strikes me as either too much or not enough: Many modern operating systems already detect if a web proxy is interfering with Internet communications, using proprietary mechanisms that are out of scope of this document. After that mechanism has run (and detected Internet connectivity is working), the DNSoD procedure described in this document should commence. The paragraph alludes to a real problem, encountered when connecting to Wi-Fi hot spots. But it is hardly a universal problem -- it is seldom encountered for example in home networks. The descripton of the problem is also fairly succint. The DNS interaction with capture portals is quite complex, and just mentioning "web proxy" looks like a handwave. If the authors want to address the issue, I suggest moving that text to a "deployment considerations" sections, and also expanding it. Of course, web portals are not the only deployment issue here. Lots depend on the deployment model. DNS-over-DTLS like DNS-over-TLS is often presented as a first hop solution, between the client and the first recursive resolver. In that case, the first recursive resolver address is known, and we have two different failure modes: failure to resolve names because DNS-over-[D]TLS is somehow blocked by a firewall; or conversely success in resolving names contrary to a local policy enforced policy, as explained in CERT Alert (TA15-240A) -- https://www.us-cert.gov/ncas/alerts/TA15-240A. The two failure modes suppose two different responses. When DTLS is detected blocked, the client has multiple possible course of actions. It could switch to using TLS. It might use some form of tunneling to avoid the blocking point. It could decide to proceed with clear text DNS requests towards the intended resolver. It might fall back to clear text DNS requests with the "locally configured" resolver. Or it might decide against using the connection, due to privacy concerns. These are complex decisions. If the client detects that it is connected to a trusted network, such as one's enterprise network, it should fall back to the local DNS. If the client detects a "capture portal," it could send a couple of clear text requests to the local server to activate the portal, and then witch to "privacy mode." If privacy is paramount and private DNS resolution is blocked, is should probably stop the connection. I don't believe that the DNS-over-DTLS draft is the proper place to address these issues. In fact, the reasoning applies just as well to DNS-over-TLS, or to the combination of DTLS and TLS. The proper course of action is probably to excise this kind of deployment considerations for the DTLS draft, and moves them to a common document for TLS and DTLS. -- Christian Huitema _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
