Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS
draft-ietf-dprive-unilateral-probing-13

# Internet AD comments for draft-ietf-dprive-unilateral-probing-12
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

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

### S4.2

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

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

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

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

Thank you for the work on this document.

I only scanned for ART issues and didn't find any. Many thanks to Bron Gondwana for his ART ART review: https://mailarchive.ietf.org/arch/msg/art/R6IORBQjJI4oZteiMhRa5OcBwMg/ and to the authors for addressing Bron's comments.

Thanks to Brian Haberman for a good shepherd writeup, and to Bron Gondwana for his ARTART review.

Thank you to Rich Salz for the SECDIR review.

I support Paul’s DISCUSS positions.

** Section 4.6.3.4
   Because this probing policy is unilateral and opportunistic, the
   client connecting under this policy MUST accept any certificate
   presented by the server.  If the client cannot verify the server's
   identity, it MAY use that information for reporting, logging, or
   other analysis purposes.  But it MUST NOT reject the connection due
   to the authentication failure, as the result would be falling back to
   cleartext, which would leak the content of the session to a passive
   network monitor.

What verification is expected? When might it trigger “reporting, logging or other analysis”?  I ask because the text seems to unambiguously say all server certificates must be accepted and then again that no connections can be rejected.