Subject: [dns-privacy] Ben Campbell's No Objection on draft-ietf-dprive-dnsodtls-13: (with COMMENT)

From: "Ben Campbell" <[email-masked]>
Date: Wed, 14 Dec 2016 13:26:23 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-dprive-dnsodtls-13: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Update: Looks like the address for Dan Wing needs to be updated.

-1: Is TCP head of line blocking considered a problem between the client
and cacheing resolver? Otherwise, between that and the potential to use
TCP fast open, the motivation for not just using TLS seems weak (which
may not be a problem for an experimental RFC.)

- 3.1: "DNS clients and servers MUST NOT use port 853 to transport
cleartext
   DNS messages. "
Am I correct to assume that this requirement is really about clients and
servers that do not implement this spec? While I see the point, how would
such a client or server even know about the restriction?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 15 Dec 2016 02:12:57 +0000

Hi Ben,

Thanks for the review. Please see inline

> -----Original Message-----
> From: Ben Campbell [mailto:[email-masked]]
> Sent: Thursday, December 15, 2016 2:56 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Tim Wicinski <[email-masked]>;
> [email-masked]; [email-masked]; [email-masked]
> Subject: Ben Campbell's No Objection on draft-ietf-dprive-dnsodtls-13: (with
> COMMENT)
> 
> 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.)
> 
> 

Yes, will update.

> 
> -1: Is TCP head of line blocking considered a problem between the client and
> cacheing resolver? 

Yes, DNS resolver may not be in the local/access networks, it can be a public DNS recursive server (e.g. OpenDNS, Google). There are other use-cases where packets may be lost or delivered out of order, like we recently enhanced Cisco routers to encrypt DNS requests (using DNSCrypt) from clients and re-direct to OpenDNS.

> Otherwise, between that and the potential to use TCP fast
> open, the motivation for not just using TLS seems weak (which may not be a
> problem for an experimental RFC.)
> 
> - 3.1: "DNS clients and servers MUST NOT use port 853 to transport cleartext
>    DNS messages. "
> Am I correct to assume that this requirement is really about clients and servers
> that do not implement this spec? While I see the point, how would such a
> client or server even know about the restriction ?

No, this requirement is for clients and servers that implement this spec (similar to https://tools.ietf.org/html/rfc7858#section-3.1) 

-Tiru