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

From: [email-masked]
Date: Sun, 18 Oct 2015 20:06:05 -0700

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

        Title           : DNS over DTLS (DNSoD)
        Authors         : Tirumaleswar Reddy
                          Dan Wing
                          Prashanth Patil
	Filename        : draft-ietf-dprive-dnsodtls-02.txt
	Pages           : 18
	Date            : 2015-10-18

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

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

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/

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 19 Oct 2015 03:10:50 +0000

This revision addresses comments from the WG. Main changes are:
* DNSoD now uses port 853
* Added support for fragmentation and reassembly
* SPKI fingerprint using sha256
* Raw public key-based authentication and cached Information Extension. 
* Updates Polling and Performance considerations Sections.

-Tiru

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Monday, October 19, 2015 8:36 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-02.txt
> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: sara <[email-masked]>
Date: Tue, 27 Oct 2015 09:59:43 +0000

> On 19 Oct 2015, at 04:10, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 

Hi, 

Thanks for this updated draft with more details on the proposed fragmentation solution. This is an initial review as I have 3 major questions at this point. 

1) I’m slightly confused as to whether the “shim” layer is a brand new protocol layer that happens to use the same format as a DNS packet for the first 17 bytes, or if this is a request to change to the DNS protocol? In either case the mechanism proposed relies on the first bit of the OpCode field being set to 0 in ’normal’ DNS packets and 1 in DTLS fragmented packets. It is true that no currently assigned OpCode value sets this bit to 1. However, if I have understood correctly this means this proposal would effectively reserve all OpCodes with values 8-15 in the DNS header, since if any in this range were assigned in future this mechanism would fail (such a reservation would require standards action, as outlined in section 2.2 of RFC6895).

2) The IANA Considerations section requests assignment of a new DTLS header (specifically for DNS fragmentation). However isn’t that something that would have to go via the TLS WG, not DPRIVE?

3) As is pointed out there are still (rare) cases where the proposed solution could fail and the draft states that if that happens the server MUST set the TC bit. However there is no statement about what a client should do in that case. Should it fallback to TLS or TCP? 

Regards

Sara.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Oct 2015 12:06:57 +0000

Hi Sara,

Thanks for the review. Please see inline [TR]

From: sara [mailto:[email-masked]]
Sent: Tuesday, October 27, 2015 3:30 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-02.txt

On 19 Oct 2015, at 04:10, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

[TR] Yes. The other alternative would be to set the first three bits in the Opcode to 1 to identify fragmented response (Opcodes 14 and 15 will have to be reserved).

[TR] Other WG had defined DTLS extensions in the past (for example https://datatracker.ietf.org/doc/rfc5764/ is the outcome of  AVT WG)

[TR] Yes, will add more details in the next revision.

-Tiru

Regards

Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 27 Oct 2015 15:10:05 +0000

> On 27 Oct 2015, at 12:06, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 
> Hi Sara,

Hi Tiru, 

Thanks for the quick response.

> [TR] Yes. The other alternative would be to set the first three bits in the Opcode to 1 to identify fragmented response (Opcodes 14 and 15 will have to be reserved).  

Reserving 2 Opcodes compared to 8 seems preferable :-) although non-optimal.  If the format of the ‘fragmentation’ protocol header were changed to contain all 4 bits of the OpCode field then only a single Opcode would be required which would minimise the impact on DNS. Do you have a name for the new fragmentation protocol to easily distinguish it from DNS in these discussions? DDF (DNS-over-DTLS Fragmentation) seems like the obvious one to me…..

FWIIW - I prefer the concept of finding a single mechanism to cater for fragmentation in both UDP and DTLS (for example, https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/ <https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/>) rather than defining a new protocol that ‘resembles’ DNS. But that would require significant protocol development. 

> [TR] Other WG had defined DTLS extensions in the past (for example https://datatracker.ietf.org/doc/rfc5764/ <https://datatracker.ietf.org/doc/rfc5764/> is the outcome of  AVT WG)

I may be wrong, but in those cases I think the charter of the working group explicitly covered extensions to core protocols, whereas DPRIVE's doesn’t?

> [TR] Yes, will add more details in the next revision.

Actually this is an optional mechanism isn’t it, so the fallback case will occur if the client chooses not to implement it. 

And I have just seen the statement in https://tools.ietf.org/html/draft-wing-dprive-profile-and-msg-flows-00#section-5 on this:

“If the DNS sever's response exceeds the EDNS0 value, the DNS server
   sets the TC (truncated) bit.  On receiving a response with the TC bit
   set, the client establishes a DNS-over-TLS connection to the same
   server, and sends a new DNS request for the same resource record.”

Sara.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 27 Oct 2015 16:02:30 +0000

Inline [TR2]

From: dns-privacy [mailto:[email-masked]] On Behalf Of Sara Dickinson
Sent: Tuesday, October 27, 2015 8:40 PM
To: Tirumaleswar Reddy (tireddy)
Cc: [email-masked]
Subject: Re: [dns-privacy] I-D Action: draft-ietf-dprive-dnsodtls-02.txt

On 27 Oct 2015, at 12:06, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:

Hi Sara,

Hi Tiru,

Reserving 2 Opcodes compared to 8 seems preferable :-) although non-optimal.  If the format of the ‘fragmentation’ protocol header were changed to contain all 4 bits of the OpCode field then only a single Opcode would be required which would minimise the impact on DNS.

[TR2] Works for me.

Do you have a name for the new fragmentation protocol to easily distinguish it from DNS in these discussions? DDF (DNS-over-DTLS Fragmentation) seems like the obvious one to me…..

[TR2] Thanks, DDF looks good ☺

FWIIW - I prefer the concept of finding a single mechanism to cater for fragmentation in both UDP and DTLS (for example, https://datatracker.ietf.org/doc/draft-muks-dns-message-fragments/) rather than defining a new protocol that ‘resembles’ DNS. But that would require significant protocol development.

[TR] In addition to the above point draft-muks-dns-message-fragments has the following issues to be resolved:
* This draft does not yet discuss RR change with re-transmissions.
* Middle boxes may not understand the new EDNS0 option and drop the response but is not a problem if used over DTLS.
* Yet to discuss fragment loss.
* Server does not know if client supports the extension, max fragments the client can handle.
* It also needs to discuss the impact of the proposed extension on DNS amplification attack.

[TR2] I don’t see the charter of AVT WG discussing extending DTLS. Anyways I am sure WG chairs can help progress the draft, once the WG finalizes the proposed DDF.

[TR2] Yup.

-Tiru

Sara.