Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt

[Tirumaleswar Reddy (tireddy)]

> -Original Message-
> From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of
> Alexander Mayrhofer
> Sent: Monday, July 25, 2016 5:04 PM
> To: dns-privacy@ietf.org
> Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt
> 
> 
> Hi,
> 
> i've reviewed the DNSoD document in version -07, and i think that the
> document is in good shape to proceed to WGLC (I suppose we'd get one or
> more DISCUSSes from the SEC AD during the IESG review, though ;). I do only
> have a couple of minor comments:
> 
> [Disclaimer: I don't know much about DTLS, admitted]
> 
> 1) The introduction explicitly lists use cases in which DNSoD provides
> confidential DNS communication (eg. stub to recursive). What is the reason
> for "limiting" this to these use cases - and why would DNSoD not provide this
> property in resolver-authoritative communications? I know the charter does
> currently not address that side of the DNS,  but I don't see any reason why it
> wouldn't work there. Proposal: change text so that is doesn't seem to exclude
> the other use cases.

Discussion of encrypting DNS messages in other use cases has just started in 
the WG and requires re-charter. 
https://tools.ietf.org/html/rfc7858#section-1 in the last paragraph explains 
that other use cases are out of scope of the doc.

> 
> 2) I think a sentence that the (wire) format of the DNS messages remains
> unchanged would be helpful.

Added.

> 
> 3) Editorial: In some cases, adding the document title in front of a reference
> would improve readability. Eg. "...which can be done with TLS Session
> Resumption without server state (RFC5077)." Instead of  "...which can be done
> with [RFC5077]."

Fixed.

> 
> 4) Do I understand correctly that in section 4 we explicitely rule out
> fragmentation, by limiting response sizes to the Path MTU (rather than the
> UDP payload size indicated via EDNS0 by the client)? 

Yes, RFC6347 in section 4.1.1 discusses that each DTLS record MUST fit within a 
single datagram.

> If yes so, why does this
> only apply to the server ?

Because only the DNS response can be larger than 512 bytes, see RFC6891.  

> Theoretically, the client could also create a query
> that exceeds the path MTU... Furthermore, (again, little knowledge of DTLS) is
> ruling out fragmentation a limitation of using DTLS, or was it a design 
> choice? 

DTLS handles fragmentation and reassembly only for handshake messages. In 
previous versions of this draft we had added support for fragmentation, 
but removed it based on discussion in the WG.

> I
> think, generally, this section is crucial and should be restructured, eg. 
> splitting
> off the size calculations from the server requirements.
> 
> 5) The statement "The largest gain for privacy is to protect the communication
> between the DNS client (the end user's machine) and its caching resolver."
> Comes a bit out of the blue - a reference here would be good. Or,
> alternatively, move this to the introduction or remove it entirely?

Moved the above line to Introduction.

> 
> 6) Section 6: Replace "plain DNS" with "plain text DNS"? Furthermore, change
> "as modern networks require DNS" to "as modern applications typically
> require DNS"

Done.

> 
> 7) Some minor restructuring of the Security Considerations section might do
> good. Eg. splitting the first sentence, like "with a ciphersuite offering
> confidentiality protection. Guidance given..." would make it clearer.

Updated.

Thanks,
-Tiru

> 
> Best,
> Alex
> 
> 
> 
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt

[Tirumaleswar Reddy (tireddy)]

> -Original Message-
> From: dns-privacy [mailto:dns-privacy-boun...@ietf.org] On Behalf Of
> Stephane Bortzmeyer
> Sent: Monday, July 25, 2016 12:34 AM
> To: Prashanth Patil (praspati) <prasp...@cisco.com>
> Cc: dns-privacy@ietf.org
> Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt
> 
> On Wed, Jul 06, 2016 at 01:54:12PM +,  Prashanth Patil (praspati)
> <prasp...@cisco.com> wrote  a message of 61 lines which said:
> 
> > The new revision addresses comments received on the list and @IETF-95.
> 
> My review of -07 : I see no reason not to move it to WG last call.
> 
> 
> 
> Technical :
> 
> > DNS client can use the authenication mechanisms discussed in
> > [I-D.ietf-dprive-dtls-and-tls-profiles]
> 
> > DNSoD client and server can use DTLS heartbeat [RFC6520]
> 
> In both cases, the language of RFC 2119 is not used. Is it on purpose?

No, will replace "can" with "MUST".

> 
> 
> 
> Editorial:
> 
> s/authenication/authentication/

Thanks, fixed in my local copy.

> 
> 
> 
> 
> Random thoughts:
> 
> Now, a stub resolver may have to try four things (UDP/53, TCP/53,
> UDP+DTLS/853 and TCP+TLS/853, all on the Standards track) before
> communicating with a resolver. Should we write a meta-document, with
> operational guidance, on how this could be done?

Yes, it will be useful.  This doc should discuss the precedence for UDP + DTLS 
verses TCP + TLS (it can consider using happy eyeballs technique).  

Cheers,
-Tiru

> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt

[Stephane Bortzmeyer]

On Wed, Jul 06, 2016 at 01:54:12PM +,
 Prashanth Patil (praspati)  wrote 
 a message of 61 lines which said:

> The new revision addresses comments received on the list and @IETF-95.

My review of -07 : I see no reason not to move it to WG last call.



Technical :

> DNS client can use the authenication mechanisms discussed in
> [I-D.ietf-dprive-dtls-and-tls-profiles]

> DNSoD client and server can use DTLS heartbeat [RFC6520]

In both cases, the language of RFC 2119 is not used. Is it on purpose?



Editorial:

s/authenication/authentication/




Random thoughts:

Now, a stub resolver may have to try four things (UDP/53, TCP/53,
UDP+DTLS/853 and TCP+TLS/853, all on the Standards track) before
communicating with a resolver. Should we write a meta-document, with
operational guidance, on how this could be done?

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

[dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-07.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the DNS PRIVate Exchange of the IETF.

Title   : DNS over DTLS (DNSoD)
Authors : Tirumaleswar Reddy
  Dan Wing
  Prashanth Patil
Filename: draft-ietf-dprive-dnsodtls-07.txt
Pages   : 11
Date: 2016-07-06

Abstract:
   DNS queries and responses are visible to network elements on the path
   between the DNS client and its server.  These queries and responses
   can contain privacy-sensitive information which is valuable to
   protect.  An active attacker can send bogus responses causing
   misdirection of the subsequent connection.

   To counter passive listening and active attacks, this document
   proposes the use of Datagram Transport Layer Security (DTLS) for DNS,
   to protect against passive listeners and certain active attacks.  As
   DNS needs to remain fast, this proposal also discusses mechanisms to
   reduce DTLS round trips and reduce DTLS handshake size.  The proposed
   mechanism runs over port 853.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dprive-dnsodtls-07


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy