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

["Christian Huitema" <[e-mail]>]

On Monday, August 8, 2016 1:29 PM, John Heidemann wrote:
> 
> On Mon, 08 Aug 2016 10:49:17 -0700, =?utf-8?Q?=F0=9F=94=93Dan_Wing?=
> 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?
> 
> 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.

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