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

[Paul Wouters via Datatracker <[e-mail]>]

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.

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