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] > 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] https://www.ietf.org/mailman/listinfo/dns-privacy
