Subject: [DNSOP] New I-D on Negative Trust Anchors

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 26 Mar 2012 07:57:59 +0000

I just posted a –00 of a draft that may be of interest to this WG. It covers an issue we have found in our DNSSEC deployment. My co-author is doing some markup of the doc now so I am hoping to post a –01 before the end of this week. (I've already found some minor typographical and grammatical errors.)

http://www.ietf.org/id/draft-livingood-negative-trust-anchors-00.txt

Feel free to share any other questions or feedback.

Regards,
Jason

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 26 Mar 2012 04:13:13 -0400

Jason,
I read the draft and like the direction of it.
It looks like you are proposing turning off a validation for domain by 
the negative trust anchor.
An alternative is to insert a negative trust anchor for a particular 
trust anchor.
In the first case there is an action required by the validator operator 
to remove the negative trust anchor,  but in the second case once an 
alternate trust anchor is available then the domain starts validating 
again.

	Olafur

On 26/03/2012 03:57, Livingood, Jason wrote:
> I just posted a –00 of a draft that may be of interest to this WG. It
> covers an issue we have found in our DNSSEC deployment. My co-author is
> doing some markup of the doc now so I am hoping to post a –01 before the
> end of this week. (I've already found some minor typographical and
> grammatical errors.)
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 26 Mar 2012 08:31:47 +0000

>the negative trust anchor.

Correct

>An alternative is to insert a negative trust anchor for a particular

Do you mean when an alternative trust anchor is used by a validating
resolver? Like the ITAR or the ISC DLV trust anchor (or for other islands
where the TLD is not signed)?

>alternate trust anchor is available then the domain starts validating

HmmmŠ So who takes the action to create or remove the (temporary?)
alternate trust anchor?

- Jason

---

From: Tony Finch <[email-masked]>
Date: Mon, 26 Mar 2012 15:24:01 +0100

Olafur Gudmundsson <[email-masked]> wrote:

> It looks like you are proposing turning off a validation for domain by the
> negative trust anchor.
> An alternative is to insert a negative trust anchor for a particular trust
> anchor.
> In the first case there is an action required by the validator operator to
> remove the negative trust anchor,  but in the second case once an alternate
> trust anchor is available then the domain starts validating again.

I think you are assuming that there is some trust anchor with which the
broken domain can be validated. But that isn't true for a lot of DNSSEC
problems, such as expired signatures or missing signatures.

There's another use for a negative trust anchor which is likely to be a
long-term setting rather than a short-term fix as the draft describes.
Internal private zones often use made-up names. (I have seen horrible
things in my mail logs like example.int for Example Corp's internal
namespace.) It's usually easier to bodge around this kind of problem than
change everything to use a real domain name; we don't want this kind of
difficulty to discourage organizations from deploying DNSSEC on their
resolvers and public DNS. These internal namespaces are often served by
software that doesn't support DNSSEC, so you can't add a positive trust
anchor to splice them into the namespace. The documentation for Unbound's
domain-insecure option talks about this kind of scenario.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Viking: Variable 3 or 4. Smooth or slight, occasionally moderate later in
northwest. Fog patches. Moderate or good, occasionally very poor.

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 27 Mar 2012 07:39:20 +0000

I read the draft, and I seem to be missing a part where a domain is intentionally insecure.
Such a situation might occur f.e. in tools investigating if DNSSEC is working properly from an end user perspective.
I can also imagine there are other situations where DNSSEC validation is broken on purpose.
So somewhere in section 7 it should state not to use negative trust anchors for domains that are intentionally insecure, though I wonder how this could be signalled (in a secure way).

- -- 
Antoin Verschuren

Technical Policy Advisor SIDN
Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/

---

From: Tony Finch <[email-masked]>
Date: Tue, 27 Mar 2012 11:04:55 +0100

Antoin Verschuren <[email-masked]> wrote:

> I read the draft, and I seem to be missing a part where a domain is
> intentionally insecure. Such a situation might occur f.e. in tools
> investigating if DNSSEC is working properly from an end user
> perspective. I can also imagine there are other situations where DNSSEC
> validation is broken on purpose. So somewhere in section 7 it should
> state not to use negative trust anchors for domains that are
> intentionally insecure, though I wonder how this could be signalled (in
> a secure way).

Do you mean insecure (no DS) or bogus (broken RRSIGs)?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dover, Wight: Northeast 4 or 5, increasing 6 at times until later. Slight or
moderate. Fair. Moderate or good.

---

From: Patrik Wallström <[email-masked]>
Date: Tue, 27 Mar 2012 12:29:33 +0200

> Do you mean insecure (no DS) or bogus (broken RRSIGs)?

I have created such a domains for exactly these purposes. This one is no longer signed (I think) but has a DS in its parent zone: trasigdnssec.se

---

From: Antoin Verschuren <[email-masked]>
Date: Tue, 27 Mar 2012 12:04:30 +0000

> Do you mean insecure (no DS) or bogus (broken RRSIGs)?

Both, and also DS  at parent but no RRSIGs or no DNSKEY in child.
Actually it does not matter how they are broken, but that the brokenness is not meant to be fixed by a negative trust anchor.

 -- 
Antoin Verschuren

---

From: "Livingood, Jason" <[email-masked]>
Date: Tue, 27 Mar 2012 15:19:23 +0000

I posted a –01 a short time ago (http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01) and listed this in open items for the next version. I may have some questions on the best way to include that.

Jason

On 3/27/12 2:04 PM, "Antoin Verschuren" <[email-masked]<mailto:[email-masked]>> wrote:

 --
Antoin Verschuren

P: +31 26 3525500  F: +31 26 3525505  M: +31 6 23368970
mailto:[email-masked]  xmpp:[email-masked]
http://www.sidn.nl/
_______________________________________________ DNSOP mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Ralf Weber <[email-masked]>
Date: Wed, 28 Mar 2012 08:02:50 +0000

Moin!

> I posted a –01 a short time ago (http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01) and listed this in open items for the next version. I may have some questions on the best way…

Ok here are some comments on that:
1. While I agree that the use of negative trust anchors will be become less necessary as we get more mature deploying the technology I don't think it will become obsolete and should not be used in the future. As long as people are handling technology there will be error, so the ability to deploy negative trust anchors has to exist indefinitely.

2. We either should enumerate all the possible failures (which is hard I guess) or just reference the examples of zone administrator errors we already had (still hard, but probably doable). While nasa.gov was the most prominent there are others that happened before. And of course there are errors that only affect certain implementations, which may relate to yet not exactly defined handling of certain aspects of the protocol, or because of the way the application handles validation. We should also name these as possible reasons for Domain validation failures.

7. The example in the text should match the graph and we should maybe add some other TLDs to show effect on TLD negative trust anchors (we already needed those ;-), and that it doesn't affect any domain beside or above it.

8. Aren't negative trust anchors a configuration option of an validator implementation (they are named the same in my companies product and are called domain-insecure in another implementation). I think this paragraph should leave the management of these to the implementation, but should urge validator implementers to include such a feature, as AFAIK only two implementations have it now.

Appendix B.: Yes we all have those purposely broke domains and we definitely don't want negative trust anchors on these. As a negative trust anchor is something an operator (human) has to deploy he certainly will look hard before he does this. So why not put an TXT record at the zone apex saying "This domain is purposely DNSSEC broken".

Another thing that we maybe could include in this documents are steps that people should do to find out if a domain is broken because of an attack or an administrator error, although these may change as the bad guys read the document.

So long
-Ralf
---
Ralf Weber
Senior Infrastructure Architect
Nominum Inc.
2000 Seaport Blvd. Suite 400 
Redwood City, California 94063
[email-masked]