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

[Paul Hoffman <[e-mail]>]

Thanks for the comments! The fixes below are in a new merge request in the repo for inclusion in a post-IESG version.

Please see my response to your last comment.

On Sep 15, 2023, at 11:03 PM, Erik Kline via Datatracker <[e-mail]> wrote:

> ### S3.1
> 
> * A 3rd option for a pool operator is to use a load-balancer that forwards
>  queries/connections on encrypted transports to only those members of the
>  pool known (e.g. via monitoring) to support the given encrypted transport.

Oooh, good call. Fixed.

> 
> ### S4.2
> 
> * There is no "port closed" ICMP message.  There is a Port Unreachable code
>  under the Destination Unreachable type category.

Fixed.

> 
> * The IP addresses given are not "two A records" but rather the values that
>  might appear in an A Resource Resource and AAAA Resource Record.

This was noted by an earlier reviewer and is already in the repo.

> 
> ### S4.4
> 
> * The use of lowercase "must" for the ALPN strings seems a bit odd.
> 
>  Should this section say that the ALPN is a "MUST"?  It could perhaps be
>  reworded to say something like "... and if an APLN is included it MUST be
>  <the_thing>".

25 years later and we're STILL getting THE 2119 capitalizion wrong. Fixed.

> 
> ### 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.

--Paul Hoffman