Re: [dns-privacy] [Ext] Restarting the discussion of draft-ietf-dprive-unilateral-probing

[Paul Hoffman <[e-mail]>]

Belated thanks for your proposed changes! It has taken this time for the three document authors to be around at the same time.

On Aug 30, 2022, at 2:09 PM, Puneet Sood <[e-mail]> wrote:

> Suggest DoET or DoQTH as abbreviations for encrypted transports. Using
> DoET in my comments below for conciseness.

We would prefer not to do that, even though it is more concise. Given that this document is about about opportunistic encryption, some folks might later object to the E in DoET.

> Comment on organization: The document goes into a lot of detail on the
> per-nameserver state to track and the actions to take on various
> events (sections 4.4, 4.6.1-4.6.5). While this is useful guidance for
> an implementor, the details will vary across implementations and are
> not of interest to readers interested in the protocol at a higher
> level. Suggest moving these implementation dsections *after* the
> higher level protocol details in section 4.

The document is actually meant for implementers, so the current organization is probably fine as-is. There *is* a lot of per-nameserver state to track, and it is important that developers see that early. Looking at your proposed reorg, I don't think that would help a general reader. We'll consider adding some protocol overview in the introduction (proposed text from the WG is welcome!).

Having said that, if we say anything in the draft about state that gets in the way of an implementer, we definitely want to fix that.

> * Section 4.1 High-level overview (for recursive resolver)
> The description here is in the context of a single NS IP. It needs to
> be broadened to the available NS IP set for the query/zone. Generally
> any NS IP with working encryption should be preferred over Do53.

We need to say more clearly that we are talking per-IP throughout the document. To make it clearer, we will move the current 4.5 to after 4.1, and strengthening our "only do it by IP" stance. We then follow it with:
   All resolvers currently keep NS sets and, in case of encrypted
   transport failures, the sets MAY be checked for other IPs instead
   of falling back to Do53 on the same IP. If there is only one IP
   address with encrypted transport, this means falling back to
   unencrypted DNS. If a nameserver has three IP addresses,
   two of which have encrypted transport and the first of those two
   causes a transport failure, the second of those two will get
   a large load due to encrypted traffic moving from the first. 


> In addition a conservative resolver may want to distribute queries
> across both Do53 and DoET to avoid sending too many queries over DoET.

The number of "too many queries over encrypted transport" will be very implementation-dependent. In fact, it is probably very system-dependent. Any resolver can inherently choose to temporarily rate-limit by sending the queries in some other fashion. So, yes, a conservative resolver might want to do that, but we can't really say anything useful in the doc to help them with it.

> Also consider the possibility that the resolver is sending queries
> from multiple source IPs (applies to large scale operators). This
> affects the state tracking variables in section 4.4.

This is already covered in Section 4.4.1; we will make it more prominent.

> * Section 4.6.6 Encrypted Transport Failures
> 
> On failure should check other NS IPs for the same zone instead of
> going to Do53 on same IP.

Agree; see the new wording above.

> * Section 4.6.8.1.  Avoid EDNS Client Subnet
> The recommendation to avoid ECS seems out of place in this document.
> In practice GPDNS and possibly other DNS resolvers already send ECS
> over plaintext. This decision would be orthogonal to unilateral
> probing.

The editor gang here are split on this. Recursive operators that adopt this strategy are clearly intending to provide privacy for their users' queries.  On the one hand, ECS is clearly an additional privacy risk; on the other hand, it is also a valuable feature when done correctly; on the gripping hand, it is often done incorrectly. Because of this, we'll take the section out of this document, but it might appear in a different "how to add privacy" document in the future.

> * Section 4.6.10 Resource Exhaustion
> Suggestion: Only initiate encrypted probing/connections after a
> minimum number of queries to a server. Not enough value to
> probe/maintain DoET state for a server which gets a small number of
> queries a day. Different operators could have different policies for
> this.

Disagree. Maintaining the "how many queries per day" state takes about as much effort as maintaining the encrypted transport state. Again, a resolver can do this if it wants to, but that would be its own operational consideration (including how to maintain the state), not something in the protocol.

Again, thanks for the in-depth comments. We'll wind this in (along with some other fixes that we have) and have a new draft out soon. We would love to see this level of comments from other resolver and authoritative server developers.

--Paul, Joey, and Dan