Subject: [dns-privacy] Review of draft-ietf-dprive-dnsodtls-03.txt

From: "Christian Huitema" <[email-masked]>
Date: Thu, 26 Nov 2015 22:01:44 -1000

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Sat, 28 Nov 2015 08:22:36 +0000

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of
> Christian Huitema
> Sent: Friday, November 27, 2015 1:32 PM
> To: [email-masked]
> Subject: [dns-privacy] Review of draft-ietf-dprive-dnsodtls-03.txt
> 
> 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

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>

> understand if the draft acknowledged that scenario.

Yes, will update draft.

> encountered for example in home networks. The descripton of the problem
> is also fairly succint. The DNS interaction with capture portals is quite
> 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
> CERT Alert (TA15-240A) -- https://www.us-cert.gov/ncas/alerts/TA15-240A.
> The two failure modes suppose two different responses.
> 
> 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
> 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.
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 28 Nov 2015 07:47:14 -1000

On Friday, November 27, 2015 10:23 PM, Tirumaleswar Reddy (tireddy) wrote:
> ...
> It's already discussed in
https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-
> 03

My bad. Yes, you are right, I somehow missed it when reading the draft.

And I agree with your proposed resolution of the other 2 issues.

-- Christian Huitema