Skip to main content

Last Call Review of draft-ietf-dnsop-negative-trust-anchors-10

Request Review of draft-ietf-dnsop-negative-trust-anchors
Requested revision No specific revision (document currently at 13)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2015-06-23
Requested 2015-06-10
Authors P Ebersman , Warren "Ace" Kumari , Chris Griffiths , Jason Livingood , Ralf Weber
Draft last updated 2015-06-25
Completed reviews Genart Last Call review of -10 by Christer Holmberg (diff)
Genart Telechat review of -11 by Christer Holmberg (diff)
Genart Telechat review of -12 by Christer Holmberg (diff)
Secdir Last Call review of -10 by Yaron Sheffer (diff)
Opsdir Last Call review of -10 by Bert Wijnen (diff)
Assignment Reviewer Yaron Sheffer
State Completed
Review review-ietf-dnsop-negative-trust-anchors-10-secdir-lc-sheffer-2015-06-25
Reviewed revision 10 (document currently at 13)
Result Has Issues
Completed 2015-06-25
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security
area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document defines a process where an ISP can declare that certain 

domain names (whose DNSSEC records are deemed misconfigured) are not 

covered by DNSSEC. The server then provides DNS resolution in response 

to client queries, where otherwise the server would have failed those 



This is more of a rant than a review, however it presents a security 

perspective that seems to be at odds with the operational-first 

perspective of the document.


I am hearing that this is a controversial draft, and I can see why. The 

draft explains very well what motivates the proposed mechanism, and the 

motivation makes sense, especially if you are an ISP. But I think the 

draft gives excellent instructions on improving the security of an 

inherently problematic usage model.

As an individual or even as a company, the local ISP is not my friend. 

State-controlled ISPs in less developed countries have been known to 

steal traffic and fake certificates in order to attack their own 

subscribers. Commercial ISPs in more developed countries throttle or 

block certain types of traffic for various reasons. Moreover, the local 

ISP is best positioned to identify the owner of individual IP endpoints 

and perform point attacks on local subscribers. DNS is an obvious attack 


Even assuming that 99.9% of us will continue to trust ISPs for DNS 

resolution, IMHO the proposed solution would be better off with more 

automation and less celebration of "trained technical personnel". For 

example, the document has a SHOULD level requirement to test the NTA 

"periodically" in order to eventually remove it. How about an 

alternative that shifts the responsibility to DevOps or to the actual 

vendors, and also empowers the .1% who maintain their own resolvers:

"NTA implementors MUST attempt to validate the domain in question once 

every MINUTE for the period of time that the Negative Trust Anchor is in 

place, until such validation is again successful, and MUST remove the 

NTA as soon as that happens."

Similarly, I would guess the process of establishing an NTA could be 

automated, e.g. by querying multiple major DNS operators over a period 

of time (maybe operators that are known to run the same brand of 

resolver). In general, automating the process is more likely to 

encourage deployment of DNSSEC by smaller ISPs than adding complex 

manual "best practices".