Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

["Christian Huitema" <[e-mail]>]

I reviewed the latest iteration of the DNS over DTLS draft (draft-ietf-dprive-dnsodtls-10). It is fine. I just have a couple of editorial nits:

 

In the beginning of section 3.1, there are two paragraphs repeating the same convoluted description of which port to use. It could probably be refactored to be a bit simpler to read. Something like one paragraph explaining which port to use, then a reference to “the selected port” in the other paragraphs.

 

The text in section 3.2 refers to the HelloVerifyRequest message of DTLS. This brings a general problem with the document, which replicates a lot of text from RFC 6347, such as the flow diagram in section 3.3. On one hand, that makes the document easy to read, but on the other hand it makes the document unnecessarily dependent on the details of DTLS implementation. The “HelloVerifyRequest” is necessary when the IP address of the client has not been verified, but the DTLS module may well be using some caching strategy to remember the required cookies, and the server may well in these cases respond immediately with a ServerHello message. We may also see clients and servers resuming old session, as actually documented in section 4. And we may well see the DTLS implementation evolve when TLS 1.3 becomes available. 

 

It would be simpler to just refer to RFC 6347 with text like “if the DTLS handshake succeeds according to [RFC6347]”, rather than replicate content. That way, we would require only minimal changes to DNS over DTLS when the DTLS spec evolves. 

 

-- Christian Huitema

 

 

 

From: dns-privacy [mailto:[e-mail]] On Behalf Of Tirumaleswar Reddy (tireddy)
Sent: Thursday, August 18, 2016 7:18 AM
To: Bob Harold <[e-mail]>
Cc: [e-mail]; [e-mail]; Warren Kumari <[e-mail]>; [e-mail]
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

 

From: Bob Harold [mailto:[e-mail]] 
Sent: Thursday, August 18, 2016 6:56 PM
To: Tirumaleswar Reddy (tireddy) <[e-mail] <mailto:[e-mail]> >
Cc: Warren Kumari <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

 

 

On Thu, Aug 18, 2016 at 1:14 AM, Tirumaleswar Reddy (tireddy) <[e-mail] <mailto:[e-mail]> > wrote:

From: Bob Harold [mailto:[e-mail] <mailto:[e-mail]> ] 
Sent: Wednesday, August 17, 2016 9:13 PM
To: Warren Kumari <[e-mail] <mailto:[e-mail]> >
Cc: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

 

 

 

On Tue, Aug 16, 2016 at 1:05 PM, Warren Kumari <[e-mail] <mailto:[e-mail]> > wrote:

Dear DPRIVE WG,

The authors of draft-ietf-dprive-dnsodtls have indicated that they
believe that the document is ready, and have asked for Working Group
Last Call.

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/

Please review this draft to see if you think it is ready for
publication and send comments to the list, clearly stating your view.

This WGLC ends Tue 30-Aug-2016.

In addition, to satisfy RFC 6702 ("Promoting Compliance with
Intellectual Property Rights (IPR)"):
Are you personally aware of any IPR that applies to
draft-ietf-dprive-dnsodtls?  If so, has this IPR been disclosed in
compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378
for more details.)

Thanks,
Warren Kumari

 

Looks good to me.  A couple grammatical concerns:

 

Section "3.1.  Session Initiation"

The last sentance might sound better by adding "therefore" in the middle:

 

"There are
   significant security issues in mixing protected and unprotected data,

            therefore
   UDP connections on a port designated by a given server for DNS-over-
   DTLS are reserved purely for encrypted communications."

 

[TR] Updated in my local copy.

 

Section "4. Performance Considerations"
This sentence does not read well to me:

"TLS False Start] which reduces round-trips
   by allowing the TLS second flight of messages (ChangeCipherSpec) to
   also contain the (encrypted) DNS query. "

 

[TR] How about the following line ?

TLS False Start [I-D.ietf-tls-falsestart] can reduce the round-trips in certain situations.

 

[BH] That would work.. I was think just change "which reduces" to "can reduce":

"TLS False Start] can reduce round-trips
   by allowing the TLS second flight of messages (ChangeCipherSpec) to
   also contain the (encrypted) DNS query. "

 

[TR] Thanks, updated.

 

-Tiru

 

 

-Tiru

 

-- 

Bob Harold