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

From: Brian Haberman <[email-masked]>
Date: Wed, 14 Aug 2019 16:40:29 -0400

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 14 Aug 2019 23:15:58 +0100

Hiya,

> 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.

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 15 Aug 2019 11:12:38 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Brian
> Haberman
> Sent: Wednesday, August 14, 2019 4:40 PM
> To: [email-masked]
> Subject: [EXTERNAL] [dns-privacy] Call for Adoption: 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.
>

I support adoption of this document, have been helping with reviews, and will continue to do so.

Scott

---

From: Hugo Connery <[email-masked]>
Date: Thu, 15 Aug 2019 14:48:52 +0200

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.

-- 
Hugo Connery, Head of IT, Dept. Environmental Engineering
Technical University of Denmark, http://www.env.dtu.dk
:(){:|:;};:

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 15 Aug 2019 11:00:02 -0400

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.

---

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 15 Aug 2019 18:40:55 +0000

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-masked]]
Sent: Thursday, 15 August 2019 17:00
To: Hugo Maxwell Connery
Cc: Brian Haberman; [email-masked]
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-masked]<mailto:[email-masked]>> wrote:
Hi DPRIVE,

1.1.1

1.1.2

3.2

Regards,  Hugo Connery

On Wed, 2019-08-14 at 16:40 -0400, Brian Haberman wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
dns-privacy mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: "James Galvin" <[email-masked]>
Date: Wed, 28 Aug 2019 13:23:21 -0400

I am not in favor of adoption of this document.

This document asserts that there “operational considerations” and at 
the same time identifies technical deficiencies that suggest there is 
protocol development work that needs to be done.

I don’t think ADoT exists.  I think most of the parts are available to 
“build” it.  However, given that there are technical gaps, I don’t 
see how this document represents operational considerations.  It is much 
better suited to motivating the development of ADoT, if that’s 
something we want to do.

Jim

---

From: Brian Dickson <[email-masked]>
Date: Wed, 28 Aug 2019 11:20:30 -0700

> by DPRIVE, and comment to the list, clearly stating your view.
I am in favor of adoption of this draft by DPRIVE.

My view is as follows:
- DNS is an ecosystem which by definition requires interoperability.
- Authority operators are a distinct subset of the participants in the DNS
ecosystem
- Authority operators of registered domains (as distinct from
delegation-only domains) have operational concerns (including scaling
issues and performance issues) that are appropriate to consider BEFORE the
development of ADoT itself.
- I.e. The draft should be input to the ADoT development process, similar
to a requirements document.
- Doing development of ADoT without this would be another example of IETF
"paper engineering", which while attractive to some participants, is very
harmful to reasonably mature ecosystems. (The "paper engineering" practice
is harmful even in green-field, IMHO.)
- Operational considerations != deployment guidelines. This is basically a
pre-emptive feedback to the standards design, based on known issues that
will affect any flavor of ADoT, no matter what it looks like.
- Deployment guidelines to operators would follow implementations, which
would follow standard development, which *should* take into consideration a
variety of factors, which this document covers.
- There is work to be done on the document, but it is a great start.

> Please also indicate if you are willing to contribute text, review, etc.

All of the above.

Brian Dickson
(Speaking for myself, but with the viewpoint of someone doing both
authority server operation and software development on authority server
software, intending to implement ADoT.)

---

From: Brian Dickson <[email-masked]>
Date: Wed, 28 Aug 2019 11:22:20 -0700

Top reply to my own post, sorry.

Even if *THIS* document is in DPRIVE (which I think it should be), it does
not necessarily imply that ADoT development itself has to be done in
DPRIVE; I think where ADoT development actually happens is a separate
question/discussion.

Brian

---

From: Rob Sayre <[email-masked]>
Date: Wed, 28 Aug 2019 16:46:02 -0700

> protocol development work that needs to be done.

This document should not be adopted.

This doesn't mean that all of the text in the document is useless, but the
term "operational considerations” does seem to be a bit Orwellian. I think
that's unintentional, and it's just a term people use when they want to
communicate all of their concerns without considering how tightly-scoped
the document should be.

thanks,
Rob

---

From: "John Levine" <[email-masked]>
Date: 28 Aug 2019 23:38:28 -0400

I'm OK with adopting it if we change the name to something like "Notes on
the design of a future authoritative DoT."

How to signal that a zone is served over ADoT without introducing
downgrade and performance issues is a hard problem to which I don't
see any good answers.  Until we tame this horse, it's premature to
start choosing paint colors for the cart.

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly