Subject: [secdir] SecDir review of draft-ietf-dnsop-negative-trust-anchors-10

From: Yaron Sheffer <[email-masked]>
Date: Fri, 19 Jun 2015 23:24:29 +0300

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 
queries.

Summary

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.

Details

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 
vector.

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".

Thanks,
	Yaron

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 29 Jun 2015 12:57:30 +0000

On 6/19/15, 4:24 PM, "Yaron Sheffer" <[email-masked]<mailto:[email-masked]>> wrote:

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.

Keeping in mind your feedback is as you say a rant, I will happily respond below and try to shed some more light on this. ;-)

As an aside, DNSSEC validation penetration would not be where it is today without NTAs. They have become critical; without them it is unlikely DNSSEC would be particularly viable. This is the unfortunate reality, and implementers are doing their best to make the network & namespace more secure within the boundaries of operational reality.

"periodically" in order to eventually remove it.

Automated vs. manual was extensively discussed in the WG and the issue concluded with the text in the document now. Among the concerns with making this more automated were whether an automated, centralized DNSSEC-disablement function would itself be a juicy target of attack to enable downgrade attacks. Aside from that, DNS recursion has always been operated locally, on a distributed basis, and there is local policy such as NTAs that has traditionally a part of this. In the end, the WG felt that not automating this was better than automating it.

How about an

"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."

FWIW, the document does not have an RFC 2119 reference and so that sort of requirement text would not carry much weight. In practice, however, implementers use NTAs sparingly and are usually in very close contact with the domain owner and are often advised by them of an estimated MTTR.

Regards,
Jason

---

From: Warren Kumari <[email-masked]>
Date: Mon, 29 Jun 2015 10:57:25 -0400

On Mon, Jun 29, 2015 at 8:57 AM, Livingood, Jason
<[email-masked]> wrote:
> On 6/19/15, 4:24 PM, "Yaron Sheffer" <[email-masked]> wrote:
>
> perspective that seems to be at odds with the operational-first perspective
> of the document.
>
>
> Keeping in mind your feedback is as you say a rant, I will happily respond
> below and try to shed some more light on this. ;-)
>
> As an aside, DNSSEC validation penetration would not be where it is today
> without NTAs. They have become critical; without them it is unlikely DNSSEC
> would be particularly viable. This is the unfortunate reality, and
> implementers are doing their best to make the network & namespace more
> secure within the boundaries of operational reality.
>
> Automated vs. manual was extensively discussed in the WG and the issue
> concluded with the text in the document now. Among the concerns with making
> this more automated were whether an automated, centralized
> DNSSEC-disablement function would itself be a juicy target of attack to
> enable downgrade attacks. Aside from that, DNS recursion has always been
> operated locally, on a distributed basis, and there is local policy such as
> NTAs that has traditionally a part of this. In the end, the WG felt that not
> automating this was better than automating it.
>
> How about an
> "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."
>
>
> FWIW, the document does not have an RFC 2119 reference and so that sort of
> requirement text would not carry much weight. In practice, however,
> implementers use NTAs sparingly and are usually in very close contact with
> the domain owner and are often advised by them of an estimated MTTR.

In addition, unless I'm very confused (entirely possible, no coffee
yet!) the .1% of people (and hopefully increasing) who run their own
resolvers are not affected by the NTA.

If you don't trust your ISP (and many people don't), you really
shouldn't be trusting them to do DNSSEC validation for you (they can
easily set the AD bit on all queries, clear it on some, etc), you
should do your own validation. If you do your own validation the NTA
is a no-op for you.

[ Apologies for delay, I was traveling (ICANN meeting...)]
W

>
> Regards,
> Jason
>
> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf