Re: [dns-privacy] Call for Adoption: draft-hal-adot-operational-considerations

[Stephen Farrell <[e-mail]>]

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