Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-01.txt
>Philip Homburg pointed out that, although impractical to determine the >Client IP before Client Cookie construction, it is feasible for a Client >to detect it when it learns a Server Cookie from a specific Server. It >can subsequently be tried to be reused for the same Server which will >fail if the Client IP has changed. > >This new (and practically implementable) requirement does not only >enhance privacy and make DNS Cookies work with the IPv6 Privacy >Extensions (by preventing tracking), it also makes them work in other >environments where Client source IP can change frequently, such as in >setups with multiple outgoing gateways. Note that my preference was a pseudo-random client cookie. I can see two issues with the current approach: 1) I'm not sure this actually fixes the IPv6 privacy extensions problem. The same client cookie can be used on different addresses if the server doesn't support cookies and the client at some point forgets that the server doesn't support cookies (and sends the server the same client cookie after a new privacy address is generated). 2) As an extension of the previous, if no server supports cookies, then the client will not change the Client Secret and continues to use the same client cookie after it moves to new location. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-01.txt
Dear dnsop, This version has an updated Client Cookie construction section in which it is now REQUIRED to change a Client Cookie when the Client IP address changes. Previously (in versions before the previous version) the Client IP address was used in Cookie construction, however that turned out to be impractical to implement and therefore dropped from the previous version recommending to disable DNS Cookies when privacy was a requirement. Philip Homburg pointed out that, although impractical to determine the Client IP before Client Cookie construction, it is feasible for a Client to detect it when it learns a Server Cookie from a specific Server. It can subsequently be tried to be reused for the same Server which will fail if the Client IP has changed. This new (and practically implementable) requirement does not only enhance privacy and make DNS Cookies work with the IPv6 Privacy Extensions (by preventing tracking), it also makes them work in other environments where Client source IP can change frequently, such as in setups with multiple outgoing gateways. Op 04-11-2019 om 21:58 schreef internet-dra...@ietf.org: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations WG of the IETF. > > Title : Interoperable Domain Name System (DNS) Server > Cookies > Authors : Ondrej Sury > Willem Toorop > Donald E. Eastlake 3rd > Mark Andrews > Filename: draft-ietf-dnsop-server-cookies-01.txt > Pages : 15 > Date: 2019-11-04 > > Abstract: >DNS cookies, as specified in RFC 7873, are a lightweight DNS >transaction security mechanism that provides limited protection to >DNS servers and clients against a variety of denial-of-service and >amplification, forgery, or cache poisoning attacks by off-path >attackers. > >This document provides precise directions for creating Server Cookies >so that an anycast server set including diverse implementations will >interoperate with standard clients. > >This document updates [RFC7873] > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dnsop-server-cookies-01 > https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-server-cookies-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-server-cookies-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
On Wed, 6 Nov 2019 at 09:38, Ray Bellis wrote: > > > On 06/11/2019 13:42, Matthew Pounsett wrote: > > I still have a few comments. There were a few comments from my review > > of -13 that weren't responded to in email, and haven't been updated in > > the text, so I'm repeating them here. > > Hi Matt, > > We sought advice from one of the Chairs as to whether in his reading > such a significant restructuring of the document was warranted when only > one participant was calling for it. > I'm not actually calling for a restructuring of the document. I'm calling for the structure of the document to be followed. Cleaning up section 3 by moving its tests to section 8 and clearly describing non-response problems instead is just following the existing structure of the document. I did leave it open for you to restructure the document if you wish, to actually combine sections 3 and 8. Perhaps this response will encourage others to speak up about whether they think either of those things are important changes. It's possible people saw my review of -13 and didn't feel the need to comment since someone else already had. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
On 06/11/2019 13:42, Matthew Pounsett wrote: I still have a few comments. There were a few comments from my review of -13 that weren't responded to in email, and haven't been updated in the text, so I'm repeating them here. Hi Matt, We sought advice from one of the Chairs as to whether in his reading such a significant restructuring of the document was warranted when only one participant was calling for it. We have not yet had a clear steer on that. kind regards, Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-no-response-issue-14.txt
I still have a few comments. There were a few comments from my review of -13 that weren't responded to in email, and haven't been updated in the text, so I'm repeating them here. As mentioned in my last review, Section 3 seems very confused about what it's trying to accomplish. Some subsections list only correct behaviour, some only list incorrect behaviour, while other sections list only a test for correct behaviour without actually describing either the correct behaviour or the commonly observed misbehaviour. These latter sections are the most confusing, because tests are expected to be in section 8, based on the current structure of the document. If the authors wish to keep the description of problem responses separate from the description of tests, then that should be done throughout the document, and not just for some tests. If the authors wish to mix testing and problem description, then that should be done consistently, and section 8 should be removed entirely. I said in my last review that this isn't an absolute requirement that should block publication, but while the information is all there to be found I still think it's better writing (and therefore an easier document to parse and act on) if sections 3 and 8 are consistent in their content. Presuming that the authors wish to keep problem description and test description separate, then section 3 should be consistent about describing at least good behaviour for each type of query and leaving off tests. Bad behaviour can be assumed to be non-response, based on the subject of the document, but incidental mention of other common misbehaviours or common reasons for misconfiguration wouldn't be out of place, I think. I've done a section-by-section review of 3.x this time, using the assumption that sections 3 and 8 will remain separate. For some sections I'm suggesting specific text to make clear what I think needs to change, but I think all of those subsections of 3 mentioned below need rewriting. Without a clear indication from the authors about which way they want the structure of the document to go, it's hard to commit the time to suggest rewrites for the entire section. It would be good to hear back from the authors about whether they think these issues are non-problems, and why, or whether they intend to address them in a later version. 3.1.1 - A test description leads ahead of correct behaviour. This section doesn't discuss non-response at all. Suggested text: If a zone is delegated to a server, that server should respond to an SOA query for that zone with an SOA record. Failing to respond at all is always incorrect, regardless of the configuration of the server. Responding with anything other than an SOA record in the Answer section indicates a bad delegation. 3.1.2 - A test description leads ahead of describing incorrect behaviour. Correct behaviour is never described. The test should be removed to section 8, and this should just describe failing to respond to unsupported QTypes, and what a correct response should look like. I'm supplying two suggested text blocks, the latter of which incorporates Viktor Dukhovni's suggestion about NOTIMP. Suggested text: Some servers fail to respond to unknown or unsupported types. If a server receives a query for a type that it doesn't recognize, or doesn't implement, it is expected to return the appropriate response as if it did recognize the type but did not have any data for that type: either NOERROR, or NXDOMAIN. or Some servers fail to respond to unknown or unsupported types, while others may respond with an incorrect rcode of NOTIMP. If a server receives a query for a type that it doesn't recognize, or doesn't implement, it is expected to return the appropriate response as if it did recognize the type but did not have any data for that type: either NOERROR, or NXDOMAIN. 3.1.3 - Good behaviour isn't described. 3.1.5 - The test in the second paragraph should be removed to section 8 3.2.1 - This section leads with a test that should be removed to section 8. The final paragraph is useful, but expected good behaviour needs to replace the first two. 3.2.2 - The last sentence of the second paragraph is potentially confusing, I think. Is it talking about misbehaviour of authoritative servers, or misinterpretation by recursive servers of a bad response from authoritative servers? I'm pretty sure it's the latter... so, text: Such answers will [may?] be misinterpreted by the client, and get discarded or treated as new requests. 3.2.3 - This section does not suffer from the problem described above. However, I think it could use some re-ordering to make it even clearer what the correct behaviour is: Some servers fail to respond to EDNS queries with ENDS options set. The original EDNS specification left this behaviour undefined [RFC2671], but the correct behaviour was clarified in [RFC6891]. Unknown EDNS options are supposed to be ignored by the server. 3.2.5, second paragraph - It's wor
