Hi DPRIVE, +1 on not adopting deployment guidelines for standards which dont exist.
So, this gives us an "order of approval". Indeed, it may mean that the AHoT op doc is never an RFC. Whatever. (and here I continue to wholly agreeing with you, but waffle on because I think this is important). The AHoT op doc is an important opportunity for galvanising work on this topic. DPRIVE is constructed to look at the "attack on the internet" that pervasive "monitoring" is (for DNS). This is the last major step on providing privacy in the DNS sphere. Its important, and it needs good, clear thought by informed engineers to create a solution that is robust, serves its purpose, and has a path for upgrade as new challenges emerge. Despite its alarmist tone (in some sections) AHoT op lays out many good recommendations (TLSv1.3, ...) and calls for the answering of questions which are particularly important to (especially large) DNS operators. If we want those operators to adopt these burdens (for burdens they are) we need to have a collaborative process by which they can assess the impact (cost, risk, ...) on their businesses. I'd love to live in a perfect word of utopian engineering purity, but I too run a (very small) network and know the 12 principles, from which I'll quote the first: "It Has To Work". If people fluffing on about potential impacts on business concerns have some minor influence on engineering design by first starting to talk about operational implications, I say "this happens all the time, and the IETF is well used to it". Sincerely, Hugo Connery ________________________________________ From: Ben Schwartz [[email protected]] Sent: Thursday, 15 August 2019 17:00 To: Hugo Maxwell Connery Cc: Brian Haberman; [email protected] Subject: Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations I have concerns about adoption of a draft on "operational considerations" for a specification ("ADoT") that doesn't exist, and therefore cannot be "operated". I think we should refrain from speculation, and wait until there is a proposed specification before attempting to provide guidance on how best to implement it. I'm glad the authors are bringing their concerns to the DPRIVE working group for discussion as we consider proposals for "ADoT". These concerns are well noted and will certainly influence future drafts on the topic. However, the purpose of working group adoption is not to inform discussion within a working group: it is to enable outgoing communication from a working group to other parties. To the extent that this draft serves to inform the work of DPRIVE, adoption is not necessary or relevant for the draft to achieve its purpose. On Thu, Aug 15, 2019 at 8:49 AM Hugo Connery <[email protected]<mailto:[email protected]>> wrote: Hi DPRIVE, Firstly, I concur with Stephen Farrell's comments. I support the document and further work on it. My comments are: 1.1.1 spelling: proection -> protection "Initial deployments of ADoT may offer an immediate expansion of the attack surface (additional port, transport protocol, and computationally expensive crypto operations for an attacker to exploit) while, in some cases, providing limited protection to end users." I find this a little "scareware". An additional port is not a threat. It what's running behind it. The "transport protocol" is worked out, right? TLS v1.3. "computationally expensive ...". Haven't our chip manufacturing friends provided hardware primitives to correspond to much of the "expensive" calculations? Yes, there will be a new service, and thus one must do the security analysis that you recommend. And, yes, TLSv1.3 means crypto and potentially many concurrent connections and that will place additional load on the AHoT server infrastructure. But "immediate expansion of the attack surface ... expensive crypto ... attacker to exploit ..." seems designed, along with the MUSTs for the studies, to scare CEOs and delay things. 1.1.2 paragraph 2: I presume you are referring to CDN's. Why not specify that? 3.2 "Static use of a pre-defined port provides on-path adversaries the ability to more easily drop or manipulate traffic intended for that port, possibly triggering resolvers to downgrade a connection back to a traditional DNS query, eliminating the encryption protections." How, if we're using TLSv1.3 with good crypto is "manipulate traffic" going to work? Without breaking the crypto you can't re-write queries successfully. Yes, you can drop it. But, this is always true. (Yes, its a downgrade attack.) "This attack is more likely to happen on the stub-to-recursive connection but is also a possible threat for recursive-to-authoritative connections." Why? Please justify. Airport and hotel networks? Regards, Hugo Connery PS: I am happy to continue to review. On Wed, 2019-08-14 at 16:40 -0400, Brian Haberman wrote: > This starts a Call for Adoption for > draft-hal-adot-operational-considerations > > The draft is available here: > https://datatracker.ietf.org/doc/draft-hal-adot-operational-considerations/ > > Please review this draft to see if you think it is suitable for > adoption > by DPRIVE, and comment to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, > etc. > > This call for adoption ends: 28 August 2019 > > Thanks, > Brian & Tim > > _______________________________________________ > dns-privacy mailing list > [email protected]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/dns-privacy -- Hugo Connery, Head of IT, Dept. Environmental Engineering Technical University of Denmark, http://www.env.dtu.dk :(){:|:;};: _______________________________________________ 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
