Skip to main content

Unilateral Opportunistic Deployment of Encrypted Recursive-to-Authoritative DNS


Éric Vyncke

No Objection

Jim Guichard
(Andrew Alston)
(Martin Duke)


Note: This ballot was opened for revision 12 and is now closed.

Éric Vyncke
Erik Kline
No Objection
Comment (2023-09-15 for -12) Sent
# Internet AD comments for draft-ietf-dprive-unilateral-probing-12
CC @ekline

* comment syntax:

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

### 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.
Francesca Palombini
No Objection
Comment (2023-09-21 for -12) Not sent
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: and to the authors for addressing Bron's comments.
Jim Guichard
No Objection
Murray Kucherawy
No Objection
Comment (2023-09-20 for -12) Sent
Thanks to Brian Haberman for a good shepherd writeup, and to Bron Gondwana for his ARTART review.
Roman Danyliw
No Objection
Comment (2023-09-19 for -12) Sent
Thank you to Rich Salz for the SECDIR review.

I support Paul’s DISCUSS positions.

** Section
   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.
Paul Wouters
(was Discuss) Abstain
Comment (2023-10-05 for -12) Sent
Based on the authors response to my DISCUSS (, I have updated by ballot to ABSTAIN.

I do not see any use of this draft. In its regular use, the user is still sending their queries in the clear initially. The draft assumes that after the initial leak, queries for the same target will be encrypted opportunistically. I tried pointing out that on most mobile devices, this is not the case due to frequent network changes and DNS cache purges. Any Operational or Security Considerations related to this were deemed out of scope. I can only conclude that no privacy is gained, and that the additional complexity in code is not worth the effort of implementing.

Additionally, since the draft requires the DNS servers to generate a certificate, the difference between generating a self-signed certificate, and using an ACME based certificate that CAN be validated and wouldn't need unilateral opportunistic security, I see even less reasons to attempt to deploy this.

As no indications are given back to the user, the draft does the enduser no harm (other than possibly introducing bugs due to added complexity on the code) and I see no reason to further block it with a DISCUSS.
Andrew Alston Former IESG member
No Objection
No Objection (for -12) Not sent

Martin Duke Former IESG member
No Objection
No Objection (for -12) Not sent