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