Hiya, On 14/08/2019 21:40, 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.
I'd definitely review. I'm not sure if eventual adoption would be a good or bad idea TBH. As of now I think I'd suggest waiting for another version or two before re-considering adoption but depending on discussion in this thread I might be more positive (or less;-). I fully agree that the analysis called-for needs to be done but am very unsure we need to reach consensus on all the text that describes that analysis. Getting that consensus may be v. hard if people come at it from radically different perspectives where some think encrypting DNS is basically dodgy and others think it's a great plan. My comments/questions below: #0 What's the target? Is this aiming to be an RFC? If so, why? If not (if it's meant to be an I-D the WG work on to help the analysis that's likely not gonna become an RFC), that may make sense, but I'm not sure what the authors' wishes are. #1 Version -02 is a good bit better than -00. So thanks to the authors for the work already done. #2 "providing limited protection to end users." still seems to be somewhat begrudging - doesn't the protection offered deserve as thorough an analysis as the operational issues? If so, will that be part of the work here? If not, why not? (For example, the size of the set of qnames for which an authoritative can answer presumably affects the level of privacy benefit accruing from ADOT, and there are likely some fairly subtle issues in that analysis, for example if 99% of queries to one server are for one popular qname.) #3 Why is 2.1 needed? The MUSTs in 4.1 are bogus anyway. #4 The draft-green reference is gone (yay!) but the text in 3.5 referring to [10] and [11] seem to be implicit recommendations to do the same thing. I will object to text that recommends MitMing TLS like that in any WG document and I suspect I'm not alone. (This is an example of where aiming for WG consensus text may be counter-productive.) #5 I don't understand the basis for 3.6 - I think such text would need to be based on some experiments but see no sign that's been done so far. The same is far more clearly true for 3.8 - that reference is years ahead of being reasonable. (Russ' draft is fine, but suggesting it for ADOT and doing so now are both IMO very premature.) #6 Passive DNS needs a mention. If ADOT were to succeed I guess it'd affect that. The percentage of traffic that could use ADOT without affecting the utility of passive DNS, while still improving privacy, would be a good thing to try figure out. (Not doing so may result in another set of vendors/service providers being needlessly angsty about improving privacy;-) Lastly, if the WG do adopt this, I would suggest that the WG chairs consider a bit of author shuffling as is the WG chairs' prerogative. While operator-focused authors (as I believe is the case for the current author-set) are absolutely required, I believe adding an author who is equally or more concerned with getting the potential privacy gains of TLS (for ADOT) may be a good plan as it might result in text on which the WG can more easily reach consensus (if the author-team have beaten one another up first, that'd maybe save a WG participant- melee later:-) Cheers, S. > > 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 >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
signature.asc
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
