> -----Original Message----- > From: dns-privacy [mailto:[email protected]] On Behalf Of > Christian Huitema > Sent: Friday, November 27, 2015 1:32 PM > To: [email protected] > Subject: [dns-privacy] Review of draft-ietf-dprive-dnsodtls-03.txt > > 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.
It's already discussed in https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-03 <snip> If the DNS server's response exceeds the EDNS0 value, the DNS server sets the TC (truncated) bit. On receiving a response with the TC bit set, the client establishes a DNS-over-TLS connection to the same server, and sends a new DNS request for the same resource record </snip> > > 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. Yes, will update draft. > > 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. Agreed, will remove this text. The unified TLS/DTLS profiles draft we plan to publish soon will discuss these issues. -Tiru > > -- Christian Huitema > > > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
