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

[Hugo Maxwell Connery <[e-mail]>]

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 [[e-mail]]
Sent: Thursday, 15 August 2019 17:00
To: Hugo Maxwell Connery
Cc: Brian Haberman; [e-mail]
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 <[e-mail]<mailto:[e-mail]>> 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
> [e-mail]<mailto:[e-mail]>
> 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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dns-privacy