Subject: [DNSOP] Security Considerations Suggestion for draft-ietf-dnsop-rfc7816bis

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 8 Jul 2019 19:00:08 +0000

I've recently been reading draft-ietf-dnsop-rfc7816bis and I'd like to propose some additional text for the Security Considerations section in the spirit of this sentence from the abstract:

"Future versions of this draft will contain descriptions of different minimisation implementation choices that have been made since the RFC 7816 first came out, as well as deployment experience."

QNAME minimization has the consequence of reduction in the amount of information seen by authoritative name server operators. Active consideration of that consequence is worth capturing as a factor to be weighed when making the choice to implement QNAME minimization, especially if there are other ways to gain privacy protection. Here's suggested text:

In addition to the performance considerations described in Section 4, there's also a security risk associated with the reduction of  data sent to authoritative name servers: they lose some of their ability to assess security threats [Kaliski-Minimum].  This ability  has proven to be useful in, for example, studies of name collision vulnerabilities [MitM-Attack-Name-Collisions]  [Client-Side-Name-Collision].  It was also instrumental in the research that led to the discovery of the JASBUG vulnerability  [ICS-ALERT-15-041-01]. The reduction will also have an impact on the level of detail available for research studies such as DNS-OARC's annual Day in the Life of the Internet (DITL) data collection exercise [DITL].

For this reason, implementers should also consider the potential impact on threat analysis and research when reducing the level of detail included in queries to authoritative name servers. Without such consideration, a collection of individual decisions to reduce query information, over time, may well have the unintended consequence of "deciding" to no longer support threat analysis and research that the operational DNS community has historically relied on.  Alternative mechanisms for facilitating threat analysis and research are beyond the scope of this document.

[Client-Side-Name-Collision] Qi Alfred Chen, Matthew Thomas, Eric Osterweil, Yulong Cao, Jie You, and Z. Morley Mao.  "Client-side Name Collision Vulnerability in the New gTLD Era: A Systematic Study".  In ACM Conference on Computer and Communications Security (CCS '17), pp. 941-956.  ACM, November 2017.
<https://acmccs.github.io/papers/p941-chenA.pdf>

[DITL]  CAIDA, "A Day in the Life of the Internet (DITL)", <http://www.caida.org/projects/ditl/>

[ICS-ALERT-15-041-01] NCCIC/ICS-CERT, "Microsoft Security Bulletin MS15-011 JASBUG", February 10, 2015, revised August 23, 2018.
<https://ics-cert.us-cert.gov/alerts/ICS-ALERT-15-041-01>

[Kaliski-Minimum] Kaliski, B., "Minimum Disclosure: What Information Does a Name Server Need to Do Its Job?", March 2015, <http://blogs.verisigninc.com/blog/entry/minimum_disclosure_what_information_does>

[MitM-Attack-Name-Collisions] Qi Alfred Chen, Eric Osterweil, Matthew Thomas, and Z. Morley Mao.  "MitM Attack by Name Collision: Cause Analysis and Vulnerability Assessment in the New gTLD Era".  In 37th IEEE Symposium on Security and Privacy (S&P '16), pp. 675-690.  IEEE, May 2016.
<https://cs.gmu.edu/~eoster/doc/MitM-Attack-by-Name-Collision-Cause-Analysis-and-WPAD-Vulnerability-Assessment-in-the-New-gTLD-Era.pdf>

Scott

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 10 Jul 2019 18:29:25 -0400

Hi Scott, some nits below 
> On Jul 8, 2019, at 3:00 PM, Hollenbeck, Scott <shollenbeck=[email-masked]> wrote:
> 
> In addition to the performance considerations described in Section 4, there's also a security risk associated with the reduction of  data sent to authoritative name servers: they lose some of their ability to assess

“data sent to authoritative name servers” 
The zone authoritative name servers get the same query with and without Query Minimization (QM) 
I think you want to say “parental name servers” i.e. servers for zones above the zone.

> security threats [Kaliski-Minimum].  This ability  has proven to be useful in, for example, studies of name collision vulnerabilities [MitM-Attack-Name-Collisions]  [Client-Side-Name-Collision].  It was also instrumental in the research that led to the discovery of the JASBUG vulnerability  [ICS-ALERT-15-041-01]. The reduction will also have an impact on the level of detail available for research studies such as DNS-OARC's annual Day in the Life of the Internet (DITL) data collection exercise [DITL].

Your arguments about visibility to researchers are true but not exclusive i.e. the same information can be derived from recursive resolvers, and from the pool of queries that still arrive without QMr. 
As for using the DITL as argument against query-minimization I think there should be some arguments that DITL collection serves a useful purpose. 

> For this reason, implementers should also consider the potential impact on threat analysis and research when reducing the level of detail included in queries to authoritative name servers. Without…

again object to the word “authoritative” 
I think this statement is not needed, it assumes that such research can only be done by operators of parental domains. 
What QM does is to disrupt operating models and data collection by intermediaries ==> that was an explicit goal 
The target of your advise is not JUST implementers of software but operators of resolvers as most resolver implementations provide a configuration option to select QM 

Olafur

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 12 Jul 2019 18:38:09 +0000

> -----Original Message-----
> From: Olafur Gudmundsson <[email-masked]>
> Sent: Wednesday, July 10, 2019 6:29 PM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [DNSOP] Security Considerations Suggestion for
> draft-ietf-dnsop-rfc7816bis
>
>
> > On Jul 8, 2019, at 3:00 PM, Hollenbeck, Scott
> <shollenbeck=[email-masked]> wrote:
> >
> > I've recently been reading draft-ietf-dnsop-rfc7816bis and I'd like to
> propose some additional text for the Security Considerations section in the
> spirit of this sentence from the abstract:
> >
> > "Future versions of this draft will contain descriptions of different
> minimisation implementation choices that have been made since the RFC
> 7816 first came out, as well as deployment experience."
> >
> > QNAME minimization has the consequence of reduction in the amount of
> information seen by authoritative name server operators. Active
> consideration of that consequence is worth capturing as a factor to be
> weighed when making the choice to implement QNAME minimization,
> especially if there are other ways to gain privacy protection. Here's suggested
> text:
> >
> > In addition to the performance considerations described in Section 4,
> > there's also a security risk associated with the reduction of  data
> > sent to authoritative name servers: they lose some of their ability to
> > assess
>
> The zone authoritative name servers get the same query with and without
> Query Minimization (QM) I think you want to say “parental name servers” i.e.
> servers for zones above the zone.

Thanks for the feedback, Olafur. I'm Ok with "parental" instead of "authoritative".

> > security threats [Kaliski-Minimum].  This ability  has proven to be useful in,
> for example, studies of name collision vulnerabilities [MitM-Attack-Name-
> Collisions]  [Client-Side-Name-Collision].  It was also instrumental in the
> research that led to the discovery of the JASBUG vulnerability  [ICS-ALERT-15-
> 041-01]. The reduction will also have an impact on the level of detail available
> for research studies such as DNS-OARC's annual Day in the Life of the
> Internet (DITL) data collection exercise [DITL].
>
>
> Your arguments about visibility to researchers are true but not exclusive i.e.
> the same information can be derived from recursive resolvers, and from the
> pool of queries that still arrive without QMr.
> As for using the DITL as argument against query-minimization I think there
> should be some arguments that DITL collection serves a useful purpose.

OK, so let's see what others have to say about the utility of mentioning DITL data collection.

> > For this reason, implementers should also consider the potential impact on
> threat analysis and research when reducing the level of detail included in
> queries to authoritative name servers. Without such consideration, a
> collection of individual decisions to reduce query information, over time, may
> well have the unintended consequence of "deciding" to no longer support
> threat analysis and research that the operational DNS community has
> historically relied on.  Alternative mechanisms for facilitating threat analysis
> and research are beyond the scope of this document.
>
> I think this statement is not needed, it assumes that such research can only
> be done by operators of parental domains.
> What QM does is to disrupt operating models and data collection by
> intermediaries ==> that was an explicit goal The target of your advise is not
> JUST implementers of software but operators of resolvers as most resolver
> implementations provide a configuration option to select QM

So how about this?

In addition to the performance considerations described in Section 4, there's also a security risk associated with the reduction of  data sent to parental name servers: they lose some of their ability to assess security threats [Kaliski-Minimum].  This ability  has proven to be useful in, for example, studies of name collision vulnerabilities [MitM-Attack-Name-Collisions]  [Client-Side-Name-Collision].  It was also instrumental in the research that led to the discovery of the JASBUG vulnerability  [ICS-ALERT-15-041-01]. The reduction will also have an impact on the level of detail available for research studies such as DNS-OARC's annual Day in the Life of the Internet (DITL) data collection exercise [DITL].

For this reason, operators should consider the potential impact on threat analysis and research when reducing the level of detail included in queries to parental name servers. Without such consideration, a collection of individual decisions to reduce query information, over time, may well have the unintended consequence of "deciding" to no longer support threat analysis and research that the operational DNS community has historically relied on.  Alternative mechanisms for facilitating threat analysis and research are beyond the scope of this document.

Scott