Subject: [DNSOP] Roman Danyliw's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 25 Oct 2021 15:02:02 -0700

Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-dns-tcp-requirements-13: 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/blog/handling-iesg-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-dnsop-dns-tcp-requirements/

----------------------------------------------------------------------
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.

----------------------------------------------------------------------
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”.

** 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?

** 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?

** 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.

** 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?

** Section 4.1.  Consider adding a reference of SYN cookies.

** 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.

** Section 6.  Per “Furthermore, as with real TCP, …”, what is “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/

** 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?

** 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.

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 28 Oct 2021 21:58:04 +0000

Hi Roman, thanks for the review.  My responses are inline.

> On Oct 25, 2021, at 3:02 PM, Roman Danyliw via Datatracker <[email-masked]> wrote:
> 
> 
> 

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.

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.

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.

Does “…in the late 1990s” work for you?

> 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?

> Is there a citation for this assertion?

How about the 2020 DNS flag day?  Https://dnsflagday.net/2020/

> 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.

> 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.

> ** Section 4.1.  Consider adding a reference of SYN cookies.

I added a reference to https://en.wikipedia.org/wiki/SYN_cookies

> 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”

> Recommend being clearer on who is being fingerprinted – s/fingerprinting/DNS

Done.

> 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.

> susceptibility to traffic analysis.

This is tied to your DISCUSS point above.

DW