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

["Tirumaleswar Reddy (tireddy)" <[e-mail]>]

Inline [TR2]

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


On 27 Oct 2015, at 12:06, Tirumaleswar Reddy (tireddy) <[e-mail]<mailto:[e-mail]>> 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.

[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.


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?

[TR] Other WG had defined DTLS extensions in the past (for example 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?

[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.


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?

[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.

[TR2] Yup.

-Tiru

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.