Subject: [dns-privacy] DPRIVE client with captive portal

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 8 Aug 2016 10:49:17 -0700

Are there documented procedures for how a DPRIVE client handles joining a network with a captive portal, or other filtering, which prevents accessing the DPRIVE DNS server?

-d

---

From: John Heidemann <[email-masked]>
Date: Mon, 08 Aug 2016 13:29:11 -0700

>Are there documented procedures for how a DPRIVE client handles joining a network with a captive portal, or other filtering, which prevents accessing the DPRIVE DNS server?

Yes.  From RFC-7858 section 4.2:

   However, a configured DNS server may be temporarily unavailable when
   configuring a network.  For example, for clients on networks that
   require authentication through web-based login, such authentication
   may rely on DNS interception and spoofing.  Techniques such as those
   used by DNSSEC-trigger [DNSSEC-TRIGGER] MAY be used during network
   configuration, with the intent to transition to the designated DNS
   provider after authentication.  The user MUST be alerted whenever
   possible that the DNS is not private during such bootstrap.

   -John Heidemann

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 8 Aug 2016 15:16:39 -0700

On Monday, August 8, 2016 1:29 PM, John Heidemann wrote:
> >Are there documented procedures for how a DPRIVE client handles joining a
> network with a captive portal, or other filtering, which prevents
accessing the
> DPRIVE DNS server?

There is also a mention of that in section 4.2 of
draft-ietf-dprive-dtls-and-tls-profiles-03. The description of "strict
privacy" includes the mention that there may be queries sent before
authenticating the server. The text says:

                            This profile can include some initial meta
queries
      (performed using Opportunistic Privacy) to securely obtain the IP
      address and authentication information for the privacy-enabling
      DNS server to which the DNS client will subsequently connect.

Then there is complement text is Section 6:

   A privacy-enabling DNS server may be temporarily unavailable when
   configuring a network.  For example, for clients on networks that
   require registration through web-based login (a.k.a. "captive
   portals"), such registration may rely on DNS interception and
   spoofing.  Techniques such as those used by DNSSEC-trigger
   [dnssec-trigger] MAY be used during network configuration, with the
   intent to transition to the designated privacy-enabling DNS servers
   after captive portal registration.  The system MUST alert by some
   means that the DNS is not private during such bootstrap.

Seems that the case is covered.

-- Christian Huitema

---

From: 🔓Dan Wing <[email-masked]>
Date: Mon, 8 Aug 2016 18:41:20 -0700

Thanks.  I searched that document, but my search terms were inadequate to find the necessary text.

-d

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 09 Aug 2016 11:48:21 -0400

> Thanks.  I searched that document, but my search terms were inadequate to find the necessary text.

patches welcome are for changes to
draft-ietf-dprive-dtls-and-tls-profiles that would have matched your
search terms :)

       --dkg