Re: [dns-privacy] [Ext] Paul Wouters' Discuss on draft-ietf-dprive-unilateral-probing-12: (with DISCUSS and COMMENT)

[Paul Hoffman <[e-mail]>]

Thank you for the thorough review! In the responses below, "fixed" means "fixed in the draft repo, waiting for a new draft". We are not ready to publish that new draft yet because we don't have responses for all the issues that have come up. We expect a new draft soon.

> ## DISCUSS
>
> ### Leaking probes
>
>        either or both of DoT and DoQ concurrently. The recursive resolver
>        remembers what opportunistic encrypted transport protocols have
>        worked recently based on a (clientIP, serverIP, protocol) tuple.
>
> This makes little sense to me. If the passive attackers sees the outgoing
> port 53 cleartext query, it doesn't even matter if DoT or DoQ is then
> established in parallel. The privacy is already lost. I strongly believe
> that DoT/DoQ should be tried first without unencrypted DNS, and only when
> that doesn't work in a very short time (eg 3s? 5s?) send out the unencrypted
> query.

The WG discussed this and came to the opposite conclusion. Only the first query to an authoritative server that offers encrypted transport will leak, as long as that authoritative server is queried at least once within the `persistence` window of three days.

At the beginning of deployment (and maybe even long after that), many authoritative servers will not support DoT or DoQ. Telling resolvers that the only way they can use opportunistic encryption is to add a delay to the majority of their authoritative side traffic would stop nearly any implementation. Some privacy leakage happens, but that privacy leakage is heavily amortized, and users won't see any penalty.

In the future, when someone specifies how to do fully authenticated recursive-to-authoritative queries, resolvers might indeed want to use such a strategy to greatly narrow the number of unencrypted requests for first queries. If there is interest in the WG, such a document might attract a lot of interest.

> ### DNS cache handling
>
> It does say anything about what it expects should happen with the
> cached DNS data through a restart.

(Assuming you meant "It does not say..."). That is correct. This document only covers how to do opportunistic encryption, not how to change the operation of the cache (in this case for the worse).

> Note that dropping the cache
> and restarting, especially on mobile devices, will lead to easy
> fingerprinting for passive attackets in recognising users when
> their browser tabs reload (eg if queries to apollo.ns.cloudflare and
> katelyn.ns.cloudflare.com. happen, even when encrypted, it could be
> a sign of the mobile device trying to reach the ACLU. If that same IP
> is trying to reach ken.ns.cloudflare.com. or jill.ns.cloudflare.com,
> it could be that ietf.org is being looked up. The two of these combined
> would most likely mean the device on or behind this IP address is dkg)
>
> While I understand that DNS cache handling over restarts is kind of out
> of scope for this document,

Indeed: it is not in scope based on the WG's charter.

> if this document is being read as "how to run
> a DNS resolver with maximum privacy on your mobile device" then without
> this advise, the whole unilateral probing gives us nothing.

Nothing in the current text suggests that it should be read that way. If you can point to where you got that impression, we can fix the text.

> (note: in
> Fedora I had this exact issue, where some people insisted on purging
> DNS cache on interface change, and I insisted on keeping DNS cache, so
> the NetworkManager got an option to tweak this behaviour). DNS cache
> handling for DNS resolvers on non-mobile devices, eg those on static
> IPs shared by many independent clients, might not need to consider this.

This sounds like you are proposing that someone (likely in the DNSOP WG) should write a new document on mobile devices and DNS caches. I can see some value in that, but nailing down such advice will be challenging given that some of our current mobile devices change how they do things from year to year. We tried to keep this document in the narrow scope given to us by the DPRIVE WG.

> ### Section 4.6.2 Pseudocode
>
> Either I don't understand the pseudo code, or it is wrong:
>
>        Otherwise:
>        * Remove Q from Do53-queries[X]
>
>        If R is successful:
>        * If Q is in Do53-queries[X]:
>          [...]
>
> Since Q was just removed from Do53-queries, isn't this condition now always false ?
>
> Also, what is "R is successful" ? because that seems to happen before
> "R is further processed".  Wouldn't processing be needed to determine
> if R is successful?
>
>        But if R is unsuccessful (e.g. timeout or connection closed):
>
> But the whole state starts with: "When a response R for query Q arrives" ???

This issue will be answered in a later response. It is related to an issue that was also brought up by one of the implementers reading the document.

>
> ### Section 4 / Section 7 : Security advise
>
> Should it not clearly state the resolver MUST enable query
> minimalization? Otherwise, sending queries to the root would leak all
> privacy even if the TLD supports DoT/DoQ. Or the same one level lower
> if the TLD doesn't support this yet.
>
> Possibly it should RECOMMEND (or even REQUIRE) using RFC 8806 to prevent
> leaking root queries.

This feels well beyond the scope of allowing resolvers to start using opportunistic encryption. What you are proposing should come from the DNSOP WG, not this document.

> (I noticed later this was mentioned in the Security Considerations, but
> I think it would be good to promote those into Section 4 as SHOULDs)

They are mentioned, and not SHOULD-level, due to scope of the WG.

> ### Zone owner recommendations ?
>
> Should zone owners get a recommendation for using out-domain nameservers
> to reduce leaking at the root and TLD? Eg if nohats.ca uses ns1.example.com
> and ns1.example.com supports DoT/DoQ, but the root and .com do not, then
> queries for nohats.ca are not leaked to the root or .com. While when using
> in-domain nameservers, the target domain is leaked.

This seems much less related to enabling opportunistic encryption than to zone admin best practices. This draft is about adding opportunistic confidentiality for encrypted transport between recursive resolvers and authoritative servers. It is not guidance for how to avoid all confidentiality leaks from recursive resolvers; that guidance could come from a different, more comprehensive draft.

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> ## Comments
>
>
> ### Section 3:
>
>        An authoritative server implementing DoT or DoQ MUST
>        authoritatively serve the same zones over all supported
>        transports. If both DoT and DoQ are offered, a nameserver's
>        reply to a particular query MUST be the same on both transports
>        (with the possible exception of how the TC bit is set)
>
> I think there might be more differences, eg EDNS0 options related
> to packet sizes.  I think what is meant to be said is:
>
>        An authoritative server implementing DoT or DoQ MUST
>        populate the repsonse from the same authoritative zone
>        data and the unencryped DNS transports. As encrypted
>        transports have their own characteristic response size
>        that might be different from the unencrypted DNS transports,
>        response sizes and response size related options (eg EDNS0)
>        and flags (eg TC bit) might vary based on the transport.

Yes, that better reflects what we wanted. Fixed.

> ### Section 3.1
>
> As Éric Vyncke also commented, a third option could be to ensure
> that the load balancer knows/probes which ports/services are
> available on the servers being load-balanced, and only sends queries
> for those ports to the authoritative servers responding to that same port.

Agree; fixed.

> ### Section 3.2
>
>        The simplest deployment would simply provide a self-issued,
>        regularly-updated X.509 certificate.
>
> Why does it need to be regularly-updated? The even more simplest solution
> would simply generate a certificate once only and use that forever.
> Although perhaps it should be made abundantly clear that any DoT or DoQ
> TLS ciphersuite MUST be one with Ephemeral DH. (so passive attackers cannot
> be given a list of known certs private keys for instant decryption)

The WG is interested in a possible future where there is a specification for fully-authenticated encryption. If that comes to pass, then specifying certificates that are shorter-lived and regularly-updated will prevent problems with resolvers that cache the certificates they see. We changed this to "One simple...".

> ### Section 4.2
>
> ICMP port closed message should be "ICMP port destination unreachable" ?

Agree; fixed.

> ### Section 4.3
>
> A damping value of 1 day seems very long. What discussion lead to this
> value instead of say, 1 hour ? Is a factor 24 that important?

This discussion happend a few times early in the draft history, sometimes in the face-to-face meetings. An approximate summary would be "it is expected that an authoritative server will only initially turn on encryption rarely, so don't allocate extra resources on the resolver or hammer the authoritative server so much".

>
> ### Section 4.4: MTI
>
>        To follow this guidance, a recursive resolver MUST implement at
>        least one of either DoT or DoQ in its capacity as a client of
>        authoritative nameservers. A recursive resolver SHOULD implement
>        the client side of DoT. A recursive resolver SHOULD implement
>        the client side of DoQ.
>
> That's a pretty odd way of saying:
>
>        To follow this guidance, a recursive resolver MUST implement
>        at least one of DoT or DoQ but SHOULD implement both,
>        in its capacity as a client of authoritative nameservers.
>
> (I think the "in its capacity as [...]" can also safely be removed.

Just saying "a recursive resolver MUST implement at least one of DoT or DoQ" is confusing because it could be talking about either the authoritative-facing side of the client-facing side. The WG specifically asked for the more careful wording here.

> ### Section 4.4: localhost
>
>        SHOULD also accept queries from its clients over some encrypted transport.
>
> Maybe add: unless it only accept queries from localhost

Good addition. Fixed.

> ### Section 4.6.1
>
> As stated in my DISCUSS, I still think a 3-5 second delay for unencrypted DNS
> packets is required, or the gain of unilateral probing becomes next to
> nothing (at least unless the entire world uses cloudflare as auth servers)

See response above.

> ### Section 4.6.3:
>
>        If the recursive resolver has a preferred encrypted transport,
>        but only a different transport is in the established state,
>        it MAY also initiate a new connection to X over its preferred
>        transport while concurrently sending the query over the
>        established transport E.
>
> I am confused by "preferred encrypted transport" and "established transport".
> Is this trying to talk about only encrypted transports and less and more
> preferred ones? Or does this include unencrypted transports? If the latter
> is included, 1) see my above comments on delays on do53, and 2) a UDP 53
> transport is not "established", only TCP 53 is. In which case, "but what
> about UDP then" ?

It is only about encrypted transports. Fixed.

> ### Section 6.1:
>
> Would it make sense to recommend an SNI using the IP address in presentation
> format as the SNI host_name? eg I assume that would be the same as the
> SNI for a request to https://192.0.2.1?
>
> I'm not sure if it is well supported these days to omit an SNI in TLS
> libraries or not.

This sounds plausible, but probably should be aimed at the TLS WG first. If they decide that this is a reasonable way to do SNI, there isn't anything here that prevents using it. The only reason to send SNI is to solicit specific credentials, and one main point of this draft is to avoid any question about those credentials.

> ### Section 7
>
> See my DISCUSS on leaking do53 and localroot / query minimalization

See above.

> It does list the leaking happy eyeballs. I still believe as mentioned
> earlier, that at least a brief attempt should be made to avoid leaking
> over port 53 immediately for every new nameserver contacted.
>
> Ahh, I see now that local root and query minimalization are mentioned.
> I think these deserve to be more than just Security Considerations,
> and be part of the rough specification of unilateral probing as this
> document defines.

See above.

> ### ection 8
>
>        and the system would need to be able to differentiate queries
>        for recursive answers from queries for authoritative answers.
>
> Isn't that just core DNS functionality (eg the Recursion Desired (RD)
> flag and the query ID) ?

Yes; fixed.

> I don't think this is an operational consideration
> for unilateral probing.

True, but it didn't exist in any other RFC we could find to reference, so it seemed reasonable to state it here rather than ignore it.

>
> ### NITS:
>
> awkward sentence: The simplest deployment would simply [...]

Fixed.

> with two A records -> with two address records

Fixed from an earlier review.

>
>        This document uses the notation E-foo to refer to the
>        foo parameter for the encrypted transport E. For example
>        DoT-persistence [...]
>
> This took me a few reads before I understood this. I recommend:
>
>        This document uses the notation <transport>-foo to refer to the
>        foo parameter for the encrypted transport <transport>. For example
>        DoT-persistence [...]

Good catch. This paragraph is wrong. We use "E-foo" to mean foo over any encrypted transport. Fixed.

Thanks again for the thorough review!

--Paul Hoffman (for Joey and dkg as well)