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 protected]> wrote: > Hi Allison, > > > > Thanks for the review. Please see inline [TR] > > > > *From:* Allison Mankin [mailto:[email protected]] > *Sent:* Wednesday, August 31, 2016 5:36 AM > *To:* Tirumaleswar Reddy (tireddy) <[email protected]> > *Cc:* Warren Kumari <[email protected]>; [email protected]; > [email protected]; [email protected]; > Allison Mankin <[email protected]>; John Heidemann <[email protected]> > *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. > > > > 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. > > > > [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 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[*]. > > > > [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: > > 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 protected]> wrote: > > > -----Original Message----- > > From: dns-privacy [mailto:[email protected]] On Behalf Of > > Stephane Bortzmeyer > > Sent: Monday, August 22, 2016 8:42 PM > > To: Warren Kumari <[email protected]> > > Cc: [email protected]; [email protected]; > draft-ietf-dprive- > > [email protected] > > Subject: Re: [dns-privacy] Start of WGLC for draft-ietf-dprive-dnsodtls. > > > > On Tue, Aug 16, 2016 at 01:05:40PM -0400, Warren Kumari > > <[email protected]> wrote a message of 38 lines which said: > > > > > 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.) > > 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 protected] > > https://www.ietf.org/mailman/listinfo/dns-privacy > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy > > >
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
