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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Paul Hoffman <[e-mail]>
> Sent: Tuesday, March 31, 2020 11:01 AM
> To: Hollenbeck, Scott <[e-mail]>
> Cc: [e-mail]
> Subject: [EXTERNAL] Re: [Ext] [DNSOP] Security Considerations Suggestion
> for draft-ietf-dnsop-rfc7816bis
> 
> On Mar 31, 2020, at 6:34 AM, Hollenbeck, Scott
> <shollenbeck=[e-mail]> wrote:
> >
> > I originally sent this to the list last July. Olafur provided some
feedback
> (which has been incorporated into the text suggested below), but it seems
> to have slipped past the document editors. Trying again since the document
> has been revived after it recently expired...
> >
> > 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. Here's
> suggested text:
> >
> > "In addition to the performance considerations described in Section 4,
> there's also a security consideration associated with the reduction of
data
> sent to parental name servers: they lose some of their ability to assess
> security threats.  This ability  has proven to be useful in, for example,
studies
> of name collision vulnerabilities.  It was also instrumental in the
research that
> led to the discovery of the JASBUG vulnerability. 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.
> >
> > 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."
> 
> Sorry for missing that message last year. I remember it now, and I
strongly
> disagree with the wording you propose.
> 
> (Disclaimer: ICANN uses the data we see at the root server we operate for
> security analysis, as does Verisign.)
> 
> Privacy-reducing exposure of data almost always can be supported as
> allowing better monitoring for security. That's always the balance. The
folks
> who run root servers who use the data coming to them for security analysis
> will naturally want more data. The folks sending queries to the root
servers
> who want more privacy will naturally want to send less data.
> 
> It is appropriate to mention this tension in the Security Considerations
> section. However, because the default is already "send full queries
> upstream", the current text seems sufficient to alert the reader of the
> privacy benefits.
> 
> Said a different way, if the wording above is needed for this document, it
is
> needed for every document that adds encryption or reduces query traffic;
> the IETF has not done that much in the past.

OK, point taken. The Security Considerations section describes the balance
between privacy benefits and performance. It would also be worth explicitly
noting that the loss of data is a forensic analysis detriment, but with no
one else expressing any concern I won't belabor the point.

Section 8 contains some text describing research results. Would be helpful
to include observations from an authoritative server operator? If so, I'll
see what I can come up with.

Scott