Hi David, All of those changes look good to me. Happy to clear the discuss when you post -07.
Cheers, S. On 25/02/16 01:12, Dave Lawrence wrote: > Stephen Farrell writes: >> Section 11.3, I like that we're recommending that ECS be >> disabled by default, but want to check one thing. This says: >> "Due to the high cache pressure introduced by ECS, the feature >> SHOULD be disabled in all default configurations." Does that >> mean that all servers SHOULD disable this by default or does >> this only apply to some servers? If the former, it should >> probably be (re-)stated somewhere early on and more prominently >> and not only stated far down in the document like this. If the >> latter, then I think you need to be more precise and I'd like to >> know why we're not preferring the more privacy friendly option >> as our default. So I hope your answer is "yeah, all servers and >> sure we can state that earlier as well" :-) > > In the draft that is pending its (presumably) final edits to make > version -07 to head to the RFC Editor, the last paragraph of the > Privacy Note (which is section 2), now says: > > We recommend that the feature be turned off by default in all > nameserver software, and that operators only enable it explicitly > in those circumstances where it provides a clear benefit for their > clients. We also encourage the deployment of means to allow users > to make use of the opt-out provided. Finally, we recommend that > others avoid techniques that may introduce additional metadata in > future work, as it may damage user trust. > > Does that adequately address your concern? > >> - abstract: I think it'd be good if the abstract noted that this >> was documenting a deployed option and not necessarily >> recommending this as the best thing ever. There's text in the >> write-up and intro that does that nicely that could work if >> reduced to one sentence, e.g. maybe something like: "This >> documents an EDNS0 option that is in active use on the Internet >> today that is intended to be revised in the near future to >> improve it's security and privacy features." > > How is this for the new abstract? > > This document describes an EDNS0 extension that is in active use > to carry information about the network that originated a DNS > query, and the network for which the subsequent response can be > cached. Since it has some known operational and privacy > shortcomings, a revision will be worked through the IETF for > improvement. > >> - 7.2.2 says "Because a client that did not use an ECS option >> might not be able to understand it, the server MUST NOT provide >> one in its response." That seems like a bit of a pity - one >> comment I was going to make was that it might be good to include >> this (or something) in a response so that a client that didn't >> ask for ECS could be informed that some DNS server is doing ECS. >> Would that actually break things? > > I don't think anyone has real experimental evidence on this. We do > see a lot of variation in the way that various DNS servers handle EDNS > in general, but I believe pretty much all of it has been with regard > to how servers handle EDNS anomalies in requests, and not with its > unexpected presence in responses. > > Given the lack of experience in this area I'd be reluctant to include > anything about it in this document, but will certainly consider > looking into it more for the revision. > >> - section 10 has RFC1918 as a SHOULD but doesn't refer to e.g. >> RFC6598 at all. RFC6890 has a MAY associated with it, but does >> refer to 6598. And what about stuff like RFC7534, which isn't >> mentioned? Is that all correct and up to date? > > I believe it is good as-is; we actually have known operational use > cases of allowing things like CGNAT through because a co-operating > resolver and authority have shared information about what the network > looks like. This is covered a little in the section on NAT > Considerations. If there's still something problematic I'd be happy > to address it. > >> - 11.1, 4th para: "Users" isn't really right. People don't know >> about any of this stuff really. "Clients" would be more accurate > > Rephrased from: > > Users who wish their full IP address to be hidden can include an > ECS option specifying the wildcard address (i.e. SOURCE > PREFIX-LENGTH of 0). > > to: > > Users who wish their full IP address to be hidden need to configure > their client software, if possible, to include an ECS option > specifying the wildcard address (i.e. SOURCE PREFIX-LENGTH of 0). > > Good? >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
