Re: [dns-privacy] [Ext] Erik Kline's No Objection on draft-ietf-dprive-unilateral-probing-12: (with COMMENT)

[Erik Kline <[e-mail]>]

> > ### S4.6.3 or S8
> >
> > * I think a very important caveat here is when a node running its own
> >  recursive resolver has just joined a network and not yet completed any
> >  captive portal probes.  Initiating encrypted transport connections prior
> >  to satisfying the captive portal testing stage could have negative
> >  consequences (especially given the MUST in S4.6.3.4).
> >
> >  Whether the state of the captive portal check(s) can be known by the
> >  recursive resolver function or not is an implementation-specific matter.
> >
> >  Yes, this really only applies to recursive resolvers running on mobile
> >  devices, but some devices can actually do this.
> >
>
> Let me first admit my ignorance about captive portals. Wouldn't your concern be true for any non-port-53 traffic that any protocol is sending when a client comes up?
>
> I'm not sure how to word your concern. I don't think it would be appropriate in Section 4.6.3 because it would in essence be saying "First refer to this piece of state that we haven't defined". It could be added to Section 8, but given my lack of expertise in captive portals, I would want the specific wording to come from someone who knows much more. If we can copy the wording from some other RFC that has the same issue, that would be best.

Yeah, I think Section 8 probably makes more sense than any other
section, as far as potential comments go.

I took a stab a potential paragraph that might be appended to Section 8:

   As discussed elsewhere, the protocol described in this document provides no
   defense against active attackers.  On networks where a captive portal is
   operating, some communications may be actively intercepted, e.g. when trying
   to redirect a user to complete an interaction with a captive portal server.
   Nodes that perform captive portal detection and Internet connectivity checks
   are RECOMMENDED to delay recursive resolver encrypted transport
   probes until after the node's Internet connectivity check policy has been
   satisfied.

(This is what the first iteration of Private DNS on Android did, FWIW.)