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<http://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]<mailto:[email protected]>> wrote: > -----Original Message----- > From: dns-privacy > [mailto:[email protected]<mailto:[email protected]>] On > Behalf Of > Stephane Bortzmeyer > Sent: Monday, August 22, 2016 8:42 PM > To: Warren Kumari <[email protected]<mailto:[email protected]>> > Cc: [email protected]<mailto:[email protected]>; > [email protected]<mailto:[email protected]>; > draft-ietf-dprive- > [email protected]<mailto:[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]<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/dns-privacy
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
