> > ### 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.) _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
