Hi Duane! > -----Original Message----- > From: iesg <iesg-boun...@ietf.org> On Behalf Of Wessels, Duane > Sent: Thursday, October 28, 2021 5:58 PM > To: Roman Danyliw <r...@cert.org> > Cc: draft-ietf-dnsop-dns-tcp-requireme...@ietf.org; dnsop@ietf.org; Suzanne > Woolf <suzworldw...@gmail.com>; dnsop-cha...@ietf.org; The IESG > <i...@ietf.org> > Subject: Re: Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp- > requirements-13: (with DISCUSS and COMMENT) > > Hi Roman, thanks for the review. My responses are inline. > > > On Oct 25, 2021, at 3:02 PM, Roman Danyliw via Datatracker > <nore...@ietf.org> wrote: > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > This document has a dedicated section for DNS over TLS, makes a number > > of configuration recommendations for DoT, and notes it in the Privacy > > Considerations. However, there is no mention of DNS over HTTPS (DoH). > > It seems like DoH should get similar treatment. > > Speaking only for myself, I am reluctant to include DoH in this draft. I > feel that > TCP and TLS are similar enough that it makes sense to cover both, but DoH is > quite a bit different.
No argument that DoH is a bit unlike the others. > If there is a concern that mentioning DoT is unfair and DoH should get equal > time then I would be in favor of discussing encrypted DNS transports more > generally, or perhaps even cutting back on encrypted transport references. I believe that if this draft is going to be the BCP to discuss DNS over TCP, all of the flavors of DNS over TCP need to be covered. I think it would be a disservice to the existing guidance to cut out discussion of encrypted transport. As you propose, I don't see a reason why the different encrypted transports couldn't be discussed together. I leave it to the deep expertise in the WG to ensure that nuances between DoT and DoH, when relevant, are called out. > But if Im in the minority here and the working group and IESG would like to > see > DoH included then we can figure out what to say. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you to Alan DeKok for the SECDIR review. > > > > ** Section 2.2. > > Yet, defying some expectations, DNS over TCP remained little-used in > > real traffic across the Internet around this time. > > > > This section doesn’t define a time period to associate with “… around > > this time”. > > Does “…in the late 1990s” work for you? Yes, thanks. > > > > > ** Section 2.2. > > Around the time > > DNSSEC was first defined, another new feature helped solidify UDP > > transport dominance for message transactions. > > > > Is that “new feature” EDNS(0) per Section 2.3? > > Yes, its a lead-in to the next section. Do you think the text needs to be > different here? No, you can leave the text as is. > > > > ** Section 2.5 > > Today, the majority of the DNS community expects, or at least has a > > desire, to see DNS over TCP transactions occur without interference. > > > > Is there a citation for this assertion? > > How about the 2020 DNS flag day? Https://dnsflagday.net/2020/ Works for me. > > ** Section 2.5. Per the use of [CHES94] and [DJBDNS] to motivate the > > position that DNS over TCP is not needed, are there more modern > > references? The former is from 1994, and the latter appears to be last > updated in 2002. > > I’m not aware of any newer, better references. It does show how long held > these beliefs are. No problem. I wanted to check. > > > > ** Section 3. > > Lastly, Section 1 of [RFC1536] is updated to eliminate the > > misconception that TCP is only useful for zone transfers. > > > > With what text is Section 1 of [RFC1536] updated? > > I suppose my suggestion would be to strike this sentence: > > UDP is, therefore, the chosen protocol for communication > though TCP is used for zone transfers. > > Later in section 1 there is a "Since UDP is used," which could be changed to > "When UDP is used," if necessary. Could you make it cleared exactly what is the old and new text relative to RFC1536. > > > > > ** Section 4.1. Consider adding a reference of SYN cookies. > > I added a reference to https://en.wikipedia.org/wiki/SYN_cookies I would recommend using Section 3.6 of RFC4987 instead. Everything else below looks good. Thanks. Regards, Roman > > > > ** Section 5.1. Does the term “DNS Wedgie” have to be used here given > > its use in American English as the name for a bullying practice? > > Judging from a google search > > (https://www.google.com/search?q="dns+wedgie";), this document appears > to be inventing the term in the context of DNS. > > I’d like my coauthor John to chime in on this. > > > > > ** Section 6. Per “Furthermore, as with real TCP, …”, what is “real TCP”? > > Removed “as with real TCP” > > > > > > ** Section 9. > > Because TCP is somewhat more complex than UDP, some characteristics > > of a TCP conversation may enable fingerprinting and tracking that is > > not possible with UDP. > > > > Recommend being clearer on who is being fingerprinted – > > s/fingerprinting/DNS client fingerprinting/ > > Done. > > > > > > ** Section 9. The text “DNS over TLS or DTLS is the recommended way > > to achieve DNS privacy” seems rather soft on recommending encrypted DNS > of any flavor. > > Was there any WG conversation to same something stronger? > > I do not recall any discussions like that, especially that werent > incorporated into > the draft. > > IMO making (stronger) recommendations about DNS privacy is starting to stray > from the purpose of this draft. > > > > > > > ** Section 9. The text mentions that TCP is more susceptible to > > fingerprinting. It would be also be worth mentioned that using DoH > > reduces susceptibility to traffic analysis. > > > This is tied to your DISCUSS point above. > > DW > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
