Subject: [Gen-art] gen-art review of draft-ietf-dprive-dnsodtls-12

From: "jouni.nospam" <[email-masked]>
Date: Thu, 17 Nov 2016 02:03:04 -0800

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-dprive-dnsodtls-12
Reviewer: Jouni Korhonen
Review Date: 2016-11-17
IETF LC End Date: 2016-11-16
IESG Telechat date: 2016-12-15

Summary:

The document is ready for publication.

Comments/questions:

o Section 3.1. has “first-come, first-served” port range. What port range this 
  actually is? Does it refer to ephemeral port range (rfc6335).

o Section 6 describes a case where an anycasted DTLS packet reaches a DNS server
  that does not have an existing security association with the client. A DTLS
  session resumption should initiated as a result. Is it possible that the next
  DTLS message again reaches another DNS server without security association, which
  would cause a new fatal alert to be returned.. etc?? If this is the case there should
  be some text pointing at this case. If I am just confused the current text is fine.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Fri, 18 Nov 2016 16:40:47 +0000

> -----Original Message-----
> From: jouni.nospam [mailto:[email-masked]]
> Sent: Thursday, November 17, 2016 3:33 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: gen-art review of draft-ietf-dprive-dnsodtls-12
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 

User Ports, range is 1024-49151; assigned based on first come and first served policy.

>   be some text pointing at this case. If I am just confused the current text is

It's the same problem as DNS-over-TCP (see https://tools.ietf.org/html/rfc7766#appendix-A), routing changes can disrupt TCP, DNS-over-TLS and DNS-over-DTLS session. 

Please suggest additional text you would like us to add.

-Tiru

---

From: "jouni.nospam" <[email-masked]>
Date: Mon, 28 Nov 2016 09:42:11 -0800

Hi,

Sorry for being under the radar. See my comments below.

> On Nov 18, 2016, at 8:40 AM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
> 

Ok. Thanks. Could you state that in the document (with a reference)?

> Please suggest additional text you would like us to add.

Easiest way here would be saying something along the lines:

OLD:
   context from the DNS-over-DTLS handshake.  But when the network
   configuration changes, a DNS-over-DTLS packet can be received by a
   server that does not have the necessary cryptographic context.  To
   encourage the client to initiate a new DTLS handshake, DNS servers
   SHOULD generate a DTLS fatal alert message in response to receiving a
   DTLS packet for which the server does not have any cryptographic
   context.  Upon receipt of an un-authenicated DTLS fatal alert, the

NEW:
   context from the DNS-over-DTLS handshake.  But when the network
   configuration or routing changes, a DNS-over-DTLS packet can be
   received by a server that does not have the necessary cryptographic
   context. Clients using DNS-over-DTLS need to always be prepared
   to re-initiate DTLS handshake and in the worst case this could even
   happen immediately after re-initiating a new handshake. To encourage
   the client to initiate a new DTLS handshake, DNS servers SHOULD
   generate a DTLS fatal alert message in response to receiving a DTLS
   packet for which the server does not have any cryptographic context.
   Upon receipt of an un-authenticated DTLS fatal alert, the ...

- Jouni

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 29 Nov 2016 05:50:38 +0000

Thanks, Jouni. Updated draft.

-Tiru

> Sent: Monday, November 28, 2016 11:12 PM
> To: Tirumaleswar Reddy (tireddy) <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: gen-art review of draft-ietf-dprive-dnsodtls-12
> 
> Hi,
> 
> >> Review Team (Gen-ART) reviews all IETF documents being processed by
> >> the IESG for the IETF Chair.  Please treat these comments just like
> >> any other last call comments.
> >>
> >> o Section 3.1. has “first-come, first-served” port range. What port
> >> range this  actually is? Does it refer to ephemeral port range (rfc6335).
> >
> >> o Section 6 describes a case where an anycasted DTLS packet reaches a
> >> DNS server  that does not have an existing security association with
> >> the client. A DTLS  session resumption should initiated as a result.
> >> Is it possible that the next  DTLS message again reaches another DNS
> >> server without security association, which  would cause a new fatal
> >> alert to be returned.. etc?? If this is the case there should  be
> >> some text pointing at this case. If I am just confused the current
> >> text is fine.
> >
> > It's the same problem as DNS-over-TCP (see
> https://tools.ietf.org/html/rfc7766#appendix-A), routing changes can disrupt
> TCP, DNS-over-TLS and DNS-over-DTLS session.
> >

---

From: "jouni.nospam" <[email-masked]>
Date: Tue, 29 Nov 2016 09:53:02 -0800

Thanks.

> On Nov 28, 2016, at 9:50 PM, Tirumaleswar Reddy (tireddy) <[email-masked]> wrote:
>