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

From: Roman Danyliw <[email-masked]>
Date: Tue, 2 Nov 2021 20:00:02 +0000

Hi Duane!

> -----Original Message-----
> From: iesg <[email-masked]> On Behalf Of Wessels, Duane
> Sent: Thursday, October 28, 2021 5:58 PM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]; [email-masked]; Suzanne
> Woolf <[email-masked]>; [email-masked]; The IESG
> <[email-masked]>
> 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
> <[email-masked]> 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
>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 3 Nov 2021 12:31:48 +0000

On 02/11/2021 20:00, Roman Danyliw wrote:

> 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 disagree, strongly.

The properties of DNS over TCP are well understood, and DNS over TLS is
(to a first approximation) a simple TLS wrapper around that.

DoH is something, umm, else.

Ray

---

From: Joe Abley <[email-masked]>
Date: Wed, 3 Nov 2021 08:49:24 -0400

On Nov 2, 2021, at 16:00, Roman Danyliw <[email-masked]> wrote:

> 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's sloppy to characterise DoH as a flavour of DNS over TCP, given that the H part doesn't necessarily involve TCP at all (and often doesn't in practice, for some ecosystems of clients and servers).

If there is any concern about DoH not receiving equitable treatment compared to DoT, I think it's sufficient simply to observe that DoH is a horse of a different colour and move on. 

Joe

---

From: Joe Abley <[email-masked]>
Date: Wed, 3 Nov 2021 08:53:09 -0400

> If there is any concern about DoH not receiving equitable treatment compared to DoT, I think it's sufficient simply to observe that DoH is a horse of a different colour and move on. 

(Those who are not familiar with that final phrase could perhaps Google it using Chrome as a worked example of HTTP over QUIC).

Joe