On Sun, Oct 11, 2020 at 11:04 PM Benjamin Kaduk <[email protected]> wrote:
> > > > Today, almost all DNS queries are sent over UDP [thomas-ditl-tcp]. > > > > > > It looks like > > > ( > > > > https://mailarchive.ietf.org/arch/msg/dns-privacy/1pZL1FA57hzE1e09mQ2HMg2aWYY/ > > > ) > > > Sara was going to follow up with the DITL authors to try and ascertain > > > whether "almost all queries" is still accurate for the "UDP" aspect, > > > though the IETF mailarchive search doesn't seem to find any more recent > > > traffic on that topic. Do we know if anyone actually heard back about > > > this (or the "sent in [the] clear" a few lines previously)? > > > I do not pretend to have the expertise needed to judge how the changes > > > deployed by major browser affect the statistics for "all DNS traffic" > > > (which presumably includes both stub-to-resolver and > > > resolver-to-authoritative). > > > > > > > > > I talked with Sara, who did reach out to the authors, and they informed > us > > that there was no updates. > > It's good that we heard back, though I guess this still doesn't match with > my intuition (and I guess Alissa made this into a discuss point). But, I > don't trust my intuition here without data to back it up :) > > They presented that paper in the fall of 2019 at DNS-OARC (https://indico.dns-oarc.net/event/32/contributions/728/ though oddly, it was not recorded). At the last OARC in September, (https://indico.dns-oarc.net/event/34/contributions/speakers) there was a talk about QNAME minimisation, but not on encryption. > > > Section 4.1 > > > > > > authentication or authorization of the client (resolver). Due to > the > > > lack of search capabilities, only a given QNAME will reveal the > > > resource records associated with that name (or that name's non- > > > existence). In other words: one needs to know what to ask for, in > > > > > > I agree with Warren that this statement ("only [...] will reveal [...] > > > or that name's non-existence") is overly strong. > > > > > > > Section 4.2 > > > > > > The DNS request includes many fields, but two of them seem > > > particularly relevant for the privacy issues: the QNAME and the > > > source IP address. "source IP address" is used in a loose sense of > > > "source IP address + maybe source port number", because the port > > > > > > In other contexts I've seen this combination referred to as the > > > "transport address". > > > > > > The QNAME is the full name sent by the user. It gives information > > > about what the user does ("What are the MX records of example.net?" > > > means he probably wants to send email to someone at example.net, > > > which may be a domain used by only a few persons and is therefore > > > very revealing about communication relationships). [...] > > > > > > (editorial) something like not-a-secret-cabal.example might make the > > > example more visceral than example.net does. > > > > > > create more problems for the user. Also, sometimes, the QNAME > embeds > > > the software one uses, which could be a privacy issue. For > instance, > > > _ldap._tcp.Default-First-Site-Name._sites.gc._msdcs.example.org. > > > > > > (nit) I trust that this can be made into a complete sentence while > > > addressing Warren's more-substantive comment. > > > > > > There are also some BitTorrent clients that query an SRV record for > > > _bittorrent-tracker._tcp.domain.example. > > > > > > In a similar vein, I'm not sure what domain.example is supposed to > > > represent here -- the domain of the author of the BitTorrent client? > > > > > > Therefore, all the issues and warnings about collection of IP > > > addresses apply here. For the communication between the recursive > > > > > > I mostly assume that this is intended to be a reference to the generic > > > concerns about "IP addresses are PII", etc., that one is ambiently > > > exposed to by reading enough about the Internet. (There does not seem > > > to be previous discussion of "collection of IP addresses" in this > > > document, which would seem to indicate that it is not trying to refer > > > back to previous text.) If so, perhaps an extra word or two would help > > > ("all the standard issues and warnings", "all the generic issues and > > > warnings", etc.) clarify the intent of the reference. > > > > > > > > I want to get back to this. > > Okay. > > > > > In both cases, the IP address > > > originating queries to the authoritative server is as sensitive as > it > > > is for HTTP [sidn-entrada]. > > > > > > I don't see how [sidn-entrada] supports the claim that > end-user-adjacent > > > DNS client IP addresses are equally sensitive as HTTP client IP > > > Addresses; it mentions "sensitive" only twice (as "privacy-sensitive", > > > admittedly, applying to such IP addresses, but as an assertion without > > > justification) and "http" only in URLs (mostly in the references) and > as > > > an example request. It would feel more natural to use an IETF > reference > > > here, as well -- e.g., RFC 7624 discusses correlating client IP > > > addresses with end users, RFC 7239 clearly covers privacy > considerations > > > for sending client IP addresses in the "forwarded" header field, and > > > there are no doubt others -- though I do note the contents of the > > > paragraph after this one. > > > > > > > > Skipping this for now. > > Okay. > > > > However, for both IPv4 and IPv6 addresses, it is > > > important to note that source addresses are propagated with queries > > > and comprise metadata about the host, user, or application that > > > originated them. > > > > > > (This "propagated with queries" is still contingent on EDNS(0) Client > > > Subnet from the previous paragraph, right?) > > > > > > > > Yes it is - do you think it needs to be re-mentioned? > > I'd prefer if it was, perhaps "are propagated with queries via EDNS(0) > Client subnet" > Ok, changed. > > > > > Section 5.1 > > > > > > not be. When other protocols will become more and more > privacy-aware > > > and secured against surveillance (e.g., [RFC8446], > > > [I-D.ietf-quic-transport]), the use of unencrypted transports for > DNS > > > may become "the weakest link" in privacy. It is noted that at the > > > time of writing there is on-going work attempting to encrypt the SNI > > > in the TLS handshake [I-D.ietf-tls-sni-encryption]. > > > > > > This mention of encrypted "SNI" (now encrypted ClientHello) comes as a > > > bit of a non sequitur. I suggest a bit of transition such as an > > > additional clause at the end of the sentences ", which is one of the > > > last remaning non-DNS cleartext identifiers of a connection target". > > > (While the actual work itself has progressed to encrypting the entire > > > ClientHello, I think it's okay to focus the exposition here on the SNI, > > > as the relevant attribute.) > > > > > > > > You're suggesting adding your clause at the end of that sentence? Like > so: > > > > It is noted that at the time of writing > > there is on-going work attempting to encrypt the SNI in the TLS > handshake > > [@RFC8744], which is one of the > > last remaining non-DNS cleartext identifiers of a connection target. > > Right, that's the suggestion. (You don't have to use it, of course.) > I've made the change, and have a note for Brian to go over as well. > > > > > > > Section 6.1.1.2 > > > > > > o communicate clearly the change in default to users > > > > > > I think this is intending to say "when the default application resolver > > > changes away from the system resolver", but the present text is perhaps > > > a little unclear about what "the change" is referring to. > > > > > > > > I see. Is this better? > > > > "communicate clearly the change to users when the default application > > resolver changes away from the system resolver" > > Better, yes. Though maybe "communicate clearly to users the change when > [...]" is better still? > Yes - that is clearer. fixed. Brian (co-chair), Eric our AD and I were going to chat about the outstanding items to make sure we're all in some agreement. tim
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
