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

From: Warren Kumari <[email-masked]>
Date: Tue, 16 Aug 2016 13:05:40 -0400

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
(as DPRIVE WG co-chair)

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Bob Harold <[email-masked]>
Date: Wed, 17 Aug 2016 11:43:13 -0400

On Tue, Aug 16, 2016 at 1:05 PM, Warren Kumari <[email-masked]> wrote:

> <https://www.ietf.org/mailman/listinfo/dns-privacy>

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

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

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

-- 
Bob Harold

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Aug 2016 05:14:32 +0000

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

On Tue, Aug 16, 2016 at 1:05 PM, Warren Kumari <[email-masked]<mailto:[email-masked]>> wrote:
Dear DPRIVE WG,

Thanks,
Warren Kumari

"There are

[TR] Updated in my local copy.

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

-Tiru

--
Bob Harold

---

From: Bob Harold <[email-masked]>
Date: Thu, 18 Aug 2016 09:26:22 -0400

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

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

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

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 18 Aug 2016 14:17:57 +0000

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

On Thu, Aug 18, 2016 at 1:14 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
From: Bob Harold [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 17, 2016 9:13 PM
To: Warren Kumari <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

Thanks,
Warren Kumari

"There are

[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

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 19 Aug 2016 11:48:50 -0700

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

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

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

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

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

Dear DPRIVE WG,

Thanks,
Warren Kumari

"There are

            therefore

[TR] Thanks, updated.

-Tiru

-Tiru

-- 

Bob Harold

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 21 Aug 2016 18:11:37 -0700

Greetings. I have read the -10 draft, and think it is ready for moving 
to the IETF. The authors have done a good job of incorporating comments 
from the WG.

Because draft-ietf-dprive-dnsodtls might be abandoned in favor of RFC 
7858 after someone implements it and compares the two, it is appropriate 
that this is set to become an Experimental RFC. After testing, if 
implementers think that there is value to the DTLS version, it can be 
put on Standards Track. It will be interesting to see how that testing 
goes when it happens; I'm particularly interested in the tradeoff of 
"TCP state is kept in the kernel" vs. "session state is kept in the 
application stack" vs. DoS-by-CPU-exhaustion.

--Paul Hoffman

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 22 Aug 2016 09:36:39 +0000

Hi Christian,

Thanks for the review, please see inline

From: Christian Huitema [mailto:[email-masked]]
Sent: Saturday, August 20, 2016 12:19 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>; 'Bob Harold' <[email-masked]>
Cc: [email-masked]; [email-masked]; 'Warren Kumari' <[email-masked]>; [email-masked]
Subject: RE: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

[TR] This section was updated to accommodate the comments from the WG that it should look similar to Section 3.1 in https://tools.ietf.org/html/rfc7858<https://tools.ietf.org/html/rfc7858#section-3.1>.

[TR] Agreed, simplified text.

-Tiru

-- Christian Huitema

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

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

Thanks,
Warren Kumari

"There are

[TR] Thanks, updated.

-Tiru

-Tiru

--
Bob Harold

---

From: Warren Kumari <[email-masked]>
Date: Mon, 22 Aug 2016 11:06:11 -0400

... and a reminder - we have just over a week to go on this WGLC.
W

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 22 Aug 2016 17:12:29 +0200

On Tue, Aug 16, 2016 at 01:05:40PM -0400,
 Warren Kumari <[email-masked]> wrote 

> https://datatracker.ietf.org/doc/draft-ietf-dprive-dnsodtls/

I've read it (the last version, -10) and, for me, it is OK, and ready
to be sent to the next step.

I would like to make it a bit shorter by deleting two sentences, "An
active attacker can send bogus responses causing misdirection of the
subsequent connection" in the abstract and "Active attackers have long
been successful at injecting bogus responses, causing cache poisoning
and causing misdirection of the subsequent connection (if attacking A
or AAAA records).  A popular mitigation against that attack is to use
ephemeral and random source ports for DNS queries [RFC5452]." in
section 1. Both are about an attack which is *not* mitigated by
DNS-over-DTLS and these two sentences are clearly out of scope. (The
relationship with DNSSEC, which solves these attacks, is already
handled in section 1.1.)

Otherwise, now that the well-knon port is not absolutely mandatory, I
suggest to change "Once the DNS client succeeds in receiving
HelloVerifyRequest from the server via UDP on the well-known port for
DNS-over-DTLS" to "Once the DNS client succeeds in receiving
HelloVerifyRequest from the server via UDP from the port used for
DNS-over-DTLS".
   
RFC 2119 mandatory flame war: "the DNS client may want to probe the
server using DTLS heartbeat" May or MAY?

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 23 Aug 2016 01:44:01 +0000

> -----Original Message-----
> From: dns-privacy [mailto:[email-masked]] On Behalf Of
> Stephane Bortzmeyer
> Sent: Monday, August 22, 2016 8:42 PM
> Cc: [email-masked]; [email-masked]; draft-ietf-dprive-
> [email-masked]
> On Tue, Aug 16, 2016 at 01:05:40PM -0400,  Warren Kumari
> <[email-masked]> wrote  a message of 38 lines which said:
> 
> I've read it (the last version, -10) and, for me, it is OK, and ready to be sent to
> the next step.
> 
> I would like to make it a bit shorter by deleting two sentences, "An active
> attacker can send bogus responses causing misdirection of the subsequent
> connection" in the abstract and "Active attackers have long been successful at
> injecting bogus responses, causing cache poisoning and causing misdirection
> of the subsequent connection (if attacking A or AAAA records).  A popular
> mitigation against that attack is to use ephemeral and random source ports
> for DNS queries [RFC5452]." in section 1. Both are about an attack which is
> *not* mitigated by DNS-over-DTLS and these two sentences are clearly out of
> scope. (The relationship with DNSSEC, which solves these attacks, is already
> handled in section 1.1.)

Done.

> 
> Otherwise, now that the well-knon port is not absolutely mandatory, I suggest
> to change "Once the DNS client succeeds in receiving HelloVerifyRequest from
> the server via UDP on the well-known port for DNS-over-DTLS" to "Once the
> DNS client succeeds in receiving HelloVerifyRequest from the server via UDP
> from the port used for DNS-over-DTLS".

Based on feedback from Christian that HelloVerifyRequest is optional from the server, removed the above line and replaced with the following lines:

   DNS client initiates DTLS handshake as described in [RFC6347],
   following the best practices specified in [RFC7525].  After DTLS
   negotiation completes, if the DTLS handshake succeeds according to
   [RFC6347] the connection will be encrypted and is now protected from
   eavesdropping.

> 
> RFC 2119 mandatory flame war: "the DNS client may want to probe the server
> using DTLS heartbeat" May or MAY?

Changed to "MAY". 

-Tiru

> 
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Allison Mankin <[email-masked]>
Date: Tue, 30 Aug 2016 20:06:26 -0400

My calendar reminds me this is the last day of this WGLC.

Overall comments:

This is a well-written spec.  I'm especially appreciative of how much the
draft has gotten aligned with RFC 7858.  I support its publication soon as
an Experimental.

Three suggestions/concerns:

Abstract and Section 1 -

I'd like to see a note added that the Experiment will be concluded when the
spec is evaluated through an implementation and some testing of the
details.

Section 1

> However TCP Fast Open [RFC7413 <https://tools.ietf.org/html/rfc7413>] can
eliminate 1-RTT in the latter case.

If the TLS Resume and the TCP Fast Open are pipelined, there is no extra
RTT in comparison with DTLS. So I think it would be better to say that with
TCP Fast Open, the implementation can achieve the same RTT efficiency as
DTLS.

Section 6

I don't recall recent WG discussion of this section on Anycast (JohnH
reviewed an earlier approach in https://www.ietf.org/mail-
archive/web/dns-privacy/current/msg00989.html).

The section states that a server receiving a DTLS message for which it
doesn't have cryptographic context SHOULD generate a DTLS Alert message to
encourage the client to try to recover.  But it acknowledges that the Alert
can't be authenticated, and so it advise the client receiving this Alert to
try two things:

   upon receipt
   of an in-window DTLS Alert, the client SHOULD continue re-
   transmitting the DTLS packet (in the event the Alert was spoofed),
   and at the same time it SHOULD initiate DTLS session resumption.
   When the DTLS client receives an authenticated DNS response from one
   of those DTLS sessions, the other DTLS session should be terminated.

Why do we think that the server is allowed to send a non-fatal Alert
message for this case?  See the MUST in RFC 6347 4.1.2.7[*].  And if it is
OK to send a non-fatal Alert message, under what conditions might the
client's two attempts have success?  The assumption seems to be a very
transient Anycast routing change (for the retransmit) or an Anycast routing
change that cycled to a previous server within the time window for the
valid resume.  One of John Heidemann's points in the message I linked to is
that there's a lack of data on Anycast impacts on transport in DNS.

Does others think that a server must send a fatal Alert (or else contradict
RFC 6347)?

In general, is the complexity of this recovery worthwhile compared with
fault-tolerantly giving up and starting over?   Is the assumed rapid and/or
cycling Anycast change common enough to justify the proposed behavior?

Suggestion: let the client give up.  Or else add language about the
assumptions and about the section being pretty theoretical/untested.

Thanks,

Allison

[*] RFC 6347 4.1.2.7:

   Unlike TLS, DTLS is resilient in the face of invalid records (e.g.,
   invalid formatting, length, MAC, etc.).  In general, invalid records
   SHOULD be silently discarded, thus preserving the association;
   however, an error MAY be logged for diagnostic purposes.
   Implementations which choose to generate an alert instead, MUST
   generate fatal level alerts to avoid attacks where the attacker
   repeatedly probes the implementation to see how it responds to
   various types of error.  Note that if DTLS is run over UDP, then any
   implementation which does this will be extremely susceptible to
   denial-of-service (DoS) attacks because UDP forgery is so easy.
   Thus, this practice is NOT RECOMMENDED for such transports.

On 22 August 2016 at 21:44, Tirumaleswar Reddy (tireddy) <[email-masked]>
wrote:

> active
> suggest
> Based on feedback from Christian that HelloVerifyRequest is optional from
> the server, removed the above line and replaced with the following lines:
>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 30 Aug 2016 20:14:14 -0400

Dear DPRIVE WG,

Tim and I discussed the WGLC earlier today and  believe that there is
sufficient support to progress the document.

Authors - please work to address the comments received (they are not
major) and let us know once you think they are acceptable.

Thanks again to everyone who commented, and special thanks to the
authors for all of the work and revisions.

... and now... profiles :-P

W

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 31 Aug 2016 05:54:00 +0000

Hi Allison,

Thanks for the review. Please see inline [TR]

From: Allison Mankin [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 5:36 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>
Cc: Warren Kumari <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Allison Mankin <[email-masked]>; John Heidemann <[email-masked]>
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

My calendar reminds me this is the last day of this WGLC.
Overall comments:
This is a well-written spec.  I'm especially appreciative of how much the draft has gotten aligned with RFC 7858.  I support its publication soon as an Experimental.

Abstract and Section 1 -

I'd like to see a note added that the Experiment will be concluded when the spec is evaluated through an implementation and some testing of the details.

[TR] I am not sure if this line is required, I don’t see other drafts with Experimental status adding this line !

Section 1

> However TCP Fast Open [RFC7413<https://tools.ietf.org/html/rfc7413>] can eliminate 1-RTT in the latter case.
If the TLS Resume and the TCP Fast Open are pipelined, there is no extra RTT in comparison with DTLS. So I think it would be better to say that with TCP Fast Open, the implementation can achieve the same RTT efficiency as DTLS.
[TR] Updated.
Section 6
I don't recall recent WG discussion of this section on Anycast (JohnH reviewed an earlier approach in https://www.ietf.org/mail-archive/web/dns-privacy/current/msg00989.html).
The section states that a server receiving a DTLS message for which it doesn't have cryptographic context SHOULD generate a DTLS Alert message to encourage the client to try to recover.  But it acknowledges that the Alert can't be authenticated, and so it advise the client receiving this Alert to try two things:

   upon receipt

   of those DTLS sessions, the other DTLS session should be terminated.
Why do we think that the server is allowed to send a non-fatal Alert message for this case?  See the MUST in RFC 6347 4.1.2.7[*].

[TR] Good point, changed to fatal alert.

-Tiru

And if it is OK to send a non-fatal Alert message, under what conditions might the client's two attempts have success?  The assumption seems to be a very transient Anycast routing change (for the retransmit) or an Anycast routing change that cycled to a previous server within the time window for the valid resume.  One of John Heidemann's points in the message I linked to is that there's a lack of data on Anycast impacts on transport in DNS.

Does others think that a server must send a fatal Alert (or else contradict RFC 6347)?

In general, is the complexity of this recovery worthwhile compared with fault-tolerantly giving up and starting over?   Is the assumed rapid and/or cycling Anycast change common enough to justify the proposed behavior ?

Suggestion: let the client give up.  Or else add language about the assumptions and about the section being pretty theoretical/untested.
Thanks,
Allison

[*] RFC 6347 4.1.2.7<http://4.1.2.7>:

On 22 August 2016 at 21:44, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
> From: dns-privacy [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Stephane Bortzmeyer
> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; draft-ietf-dprive-
> [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> wrote  a message of 38 lines which said:
>

Done.

Changed to "MAY".

-Tiru

> [email-masked]<mailto:[email-masked]>

_______________________________________________
dns-privacy mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Allison Mankin <[email-masked]>
Date: Wed, 31 Aug 2016 09:42:40 -0400

Tiru,

Thanks for your response.  I guess the Chairs and ADs will make the call
about whether there's a note motivating the Experimental status.

Wrt to your change about anycast, once the Alert is fatal, do you have the
client give up the association versus trying to resume a past association?

Allison

On 31 August 2016 at 01:54, Tirumaleswar Reddy (tireddy) <[email-masked]>
wrote:

> *From:* Allison Mankin [mailto:[email-masked]]
> *Sent:* Wednesday, August 31, 2016 5:36 AM
> *To:* Tirumaleswar Reddy (tireddy) <[email-masked]>
> *Cc:* Warren Kumari <[email-masked]>; [email-masked];
> [email-masked]; [email-masked];
> Allison Mankin <[email-masked]>; John Heidemann <[email-masked]>
> I'd like to see a note added that the Experiment will be concluded when
> the spec is evaluated through an implementation and some testing of the
> details.
>
>
>
> > However TCP Fast Open [RFC7413 <https://tools.ietf.org/html/rfc7413>]
> can eliminate 1-RTT in the latter case.
>
> message for this case?  See the MUST in RFC 6347 4.1.2.7[*].
>
>
>
> And if it is OK to send a non-fatal Alert message, under what conditions
> might the client's two attempts have success?  The assumption seems to be a
> very transient Anycast routing change (for the retransmit) or an Anycast
> routing change that cycled to a previous server within the time window for
> the valid resume.  One of John Heidemann's points in the message I linked
> to is that there's a lack of data on Anycast impacts on transport in DNS.
>
> cycling Anycast change common enough to justify the proposed behavior ?
>
>
>
> On 22 August 2016 at 21:44, Tirumaleswar Reddy (tireddy) <

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Wed, 31 Aug 2016 14:53:56 +0000

From: Allison Mankin [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 7:13 PM
To: Tirumaleswar Reddy (tireddy) <[email-masked]>
Cc: Warren Kumari <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; John Heidemann <[email-masked]>
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

Tiru,
Thanks for your response.  I guess the Chairs and ADs will make the call about whether there's a note motivating the Experimental status.
Wrt to your change about anycast, once the Alert is fatal, do you have the client give up the association versus trying to resume a past association ?
[TR] Since the fatal alert is not authenticated, it will try both DTLS session resumption and using the existing DTLS association to figure out if the alert is sent by an attacker.
-Tiru
Allison

On 31 August 2016 at 01:54, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Allison,

From: Allison Mankin [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 31, 2016 5:36 AM
To: Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>>
Cc: Warren Kumari <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Allison Mankin <[email-masked]<mailto:[email-masked]>>; John Heidemann <[email-masked]<mailto:[email-masked]>>
Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls.

Abstract and Section 1 -

Section 1

   upon receipt

-Tiru

Done.

Changed to "MAY".

-Tiru

---

From: Tim Wicinski <[email-masked]>
Date: Wed, 31 Aug 2016 15:33:53 -0400

On 8/31/16 1:54 AM, Tirumaleswar Reddy (tireddy) wrote:
> *From:*Allison Mankin [mailto:[email-masked]]
> This is a well-written spec.  I'm especially appreciative of how much
> the draft has gotten aligned with RFC 7858.  I support its publication
> soon as an Experimental.
>
>
>
> [TR] I am not sure if this line is required, I don’t see other drafts
> with Experimental status adding this line !
>
>

WG Chair here.  In conversations with our A-D on this draft, the lack of 
any appearance of an implementation feels that this needs to be spelled 
out - one suggestion would be an "Implementation Section"

https://tools.ietf.org/html/rfc6982

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Thu, 1 Sep 2016 03:28:40 +0000

> From: dns-privacy [mailto:[email-masked]] On Behalf Of Tim
> Wicinski
> Sent: Thursday, September 1, 2016 1:04 AM
> To: [email-masked]
> > I'd like to see a note added that the Experiment will be concluded
> > when the spec is evaluated through an implementation and some testing
> > of the details.
> >
> >
> >
> > [TR] I am not sure if this line is required, I don't see other drafts
> WG Chair here.  In conversations with our A-D on this draft, the lack of any
> appearance of an implementation feels that this needs to be spelled out - one
> suggestion would be an "Implementation Section"
> 

Thanks, I will add the following Note to Introduction Section:
DNS-over-DTLS is an experimental update to DNS, and the experiment will be concluded when the specification is evaluated through implementations and interoperability testing.

Cheers,
-Tiru