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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Paul,

One question/comment on one of your discuss comments inline below ...

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Paul Wouters via Datatracker
> Sent: 19 September 2023 03:59
> To: The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; dns-
> [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Paul Wouters' Discuss on draft-ietf-dprive-unilateral-probing-12: (with
> DISCUSS and COMMENT)
> 
> Paul Wouters has entered the following ballot position for
> draft-ietf-dprive-unilateral-probing-12: Discuss
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-
> ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dprive-unilateral-probing/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> # SEC AD comments for draft-ietf-dprive-unilateral-probing-12
> CC @paulwouters
> 
> * 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/
> 
> ## 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.
[Rob Wilton (rwilton)] 

This makes sense, but do we know what proportion of authoritative servers will have DoT/DoQ enabled?  E.g., is this something that the latest version of common DNS server software enables by default, or does it require extract proactive configuration?

I can imagine that if lots of users hit a 3-5s delays for their queries then that could be really annoying.

This is also potentially something that could be changed in the future.  I.e., default to also sending in the clear now, but with a plan to subsequently change the default behaviour a couple of years down the line.  I.e., a phased migration.

Regards,
Rob


> 
> ### DNS cache handling
> 
> It does say anything about what it expects should happen with the
> cached DNS data through a restart. 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, 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. (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.
> 
> ### 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" ???
> 
> ### 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.
> 
> (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)
> 
> ### 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.
> 
> 
> ----------------------------------------------------------------------
> 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.
> 
> ### 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.
> 
> ### 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)
> 
> 
> ### Section 4.2
> 
> ICMP port closed message should be "ICMP port destination unreachable" ?
> 
> ### 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?
> 
> ### 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.
> 
> ### Section 4.4: localhost
> 
>         SHOULD also accept queries from its clients over some encrypted
> transport.
> 
> Maybe add: unless it only accept queries from localhost
> 
> 
> ### 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)
> 
> ### 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" ?
> 
> ### 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.
> 
> ### Section 7
> 
> See my DISCUSS on leaking do53 and localroot / query minimalization
> 
> 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.
> 
> ### 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) ? I don't think this is an operational consideration
> for unilateral probing.
> 
> ### NITS:
> 
> awkward sentence: The simplest deployment would simply [...]
> 
> with two A records -> with two address records
> 
>         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 [...]
> 
>