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

Reply via email to