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

[Roman Danyliw <[e-mail]>]

Hi Duane!

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