Subject: [DNSOP] Posted draft-livingood-negative-trust-anchors-03

From: "Livingood, Jason" <[email-masked]>
Date: Sat, 16 Feb 2013 22:20:22 +0000

I just posted (finally, I know) an update to draft-livingood-negative-trust-anchors, which you can find at https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/.

This update incorporates feedback from Paul Vixie, Antoin Verschuren, Patrik Wallstrom, Patrik Falstrom, Marc Lampo, Ralf Weber, Wes Hardaker, Nick Weaver, Tony Finch, Shane Kerr, Joe Abley, Murray Kucherawy, and Olafur Gudmundsson.

The are six critical open issues documented at the end of the I-D.

But the most important questions for this WG are:
1 – Is this worth consideration as a WG I-D or should it continue only as an individual I-D?
2 – If the answer to #1 is that it should be a WG I-D, would you like a brief discussion of the open issues at IETF 86?

Thanks!
Jason

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Feb 2013 23:04:32 +0000

I think this is important work.   I have to confess that I haven't followed the development of this draft, so this may be an observation that's already been addressed, but I'm concerned that there's nothing in this document about ensuring that the negative trust anchor is trustworthy through validation other than through the X.509 CA infrastructure currently used for TLS.

The problem with this is that it means that a compromised CA (of which there have been a number recently) can be used as an attack on the DNSSEC validation chain.   In addition, some CAs have been known to issue Certs for the express purpose of circumventing privacy and authentication features of X.509 certs.

DANE has recently published documents that leverage the DNSSEC infrastructure to protect organizations that have implemented DNSSEC from X.509 PKI attacks.   If you use that same PKI to validate negative trust anchors, you're effectively invalidating the security model of those RFCs.

I think therefore that using X.509 certs as negative trust anchors is a really bad idea, and I would suggest that it might be worth proposing a mechanism in your draft that does not rely on such trust anchors.

I would suggest that the right solution is to rely on the DNSSEC security infrastructure to publish negative trust anchors, rather than relying on RFC5280.   I realize that this means more work, probably for DNSEXT, the chairs of which were hoping for a vacation after completing their current work, but I think this would be a much better option nevertheless.

Again, sorry if I'm misunderstanding what you're proposing.

---

From: Joe Abley <[email-masked]>
Date: Sat, 16 Feb 2013 15:21:43 -0800

> I would suggest that the right solution is to rely on the DNSSEC security infrastructure to publish negative trust anchors, rather than relying on RFC5280.   I realize that this means more work, pr…

I'm confused where you drew the reference to 5280 from (or X.509). I don't see anything in the draft that concerns publication or automatic retrieval of NTAs from elsewhere; which section did I miss?

I do quite like the idea of being able to publish a policy for a family of validators, however. I like the idea of being able to bring up a validator and subscribe consciously to the policy in such a zone, along the lines of "I'll disable validation for anything I've noticed needs to be handled that way, plus anything that Comcast is willing to tell me about their current validation policy because they know what they are doing". This has advantages for me as a validator operator, and advantages for others who might want to debug the output of my validator with reference to my current validation policy.

I like the idea of such a policy being published in the DNS, also.

Given that validators already have hooks to disable validation for particular domains, and assuming we don't necessarily need to invent new RRTypes to encapsulate that policy in the DNS, I don't necessarily see dnsext work in here. A convention about how to represent this kind of policy in the DNS seems like it could be dnsop work, though.

Jason: you didn't ask directly, but if the working group was polled to determine support for adopting this document, I would say yes and volunteer to review it.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Sat, 16 Feb 2013 23:32:28 +0000

> I'm confused where you drew the reference to 5280 from (or X.509). I don't see anything in the draft that concerns publication or automatic retrieval of NTAs from elsewhere; which section did I mis…

Sorry, I was one RFC deeper in the reference tree than I thought.   The draft that Jason's draft references is RFC5914, not RFC5280, in Section 7.   RFC5914 in turn references RFC5280.   :)

> I do quite like the idea of being able to publish a policy for a family of validators, however. I like the idea of being able to bring up a validator and subscribe consciously to the policy in such…

Yes, this does have advantages, although Comcast's security infrastructure may be much less secure than the infrastructure of the zones it could invalidate.

> Given that validators already have hooks to disable validation for particular domains, and assuming we don't necessarily need to invent new RRTypes to encapsulate that policy in the DNS, I don't ne…

If it's represented in the DNS, we need to talk about the security model.   I guess we do anyway, but the point is that merely having an ops doc that stashes it in the DNS somewhere isn't going to be enough.

> Jason: you didn't ask directly, but if the working group was polled to determine support for adopting this document, I would say yes and volunteer to review it.

I want to hear Jason's response to my possibly out-from-left-field comments before making any such commitment.   :)

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 16 Feb 2013 16:43:49 -0800

Ted's misunderstanding of what you are proposing is a valid one. You don't actually say what a negative trust anchor is, and what it is a trust anchor for, until section 7. Readers such as Ted (and myself!) will have strong prejudices by then.

I would want to see something in the Introduction saying something like:

This document discusses trust anchors for DNSSEC. A "negative trust anchor" is equivalent to a "regular" DNSSEC trust anchor for a particular instance of a recursive validating resolver. A negative trust anchor is quite different from regular DNSSEC trust anchors in that they are local, temporary, and definitely not distributed by IANA. They are trust anchors only for DNSSEC, not for PKIX.

That should help set the tone for the following sections that say how to use them, and then the much later sections on what they actually are.

--Paul Hoffman

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 17 Feb 2013 14:57:26 +0000

On 2/16/13 6:32 PM, "Ted Lemon" <[email-masked]> wrote:

>> I'm confused where you drew the reference to 5280 from (or X.509). I
>>don't see anything in the draft that concerns publication or automatic
>>retrieval of NTAs from elsewhere; which section did I miss?
>
>Sorry, I was one RFC deeper in the reference tree than I thought.   The
>draft that Jason's draft references is RFC5914, not RFC5280, in Section
>7.   RFC5914 in turn references RFC5280.   :)

A Negative Trust Anchor should IMO be locally configured and not rely upon
any external validation or sourcing for the Negative Trust Anchor(s). It
basically tells the recursive resolver to not perform (skip) DNSSEC
validation on a specific domain name for which a Negative Trust Anchor has
been locally configured. Since it would be locally configured it should
not rely on the CA infrastructure at all, and all of the inherent issues
of that - or need to rely on certificate revocations and whatnot.

Also, if a domain has already messed up their DNSSEC signing operations,
it is unlikely they'd figure out a way to properly sign a Negative Trust
Anchor or anything else for that matter.

I hope that helps, assuming of course that I understood the question
relating RFC5280 to this I-D. :-)

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 17 Feb 2013 15:00:53 +0000

On 2/16/13 6:21 PM, "Joe Abley" <[email-masked]> wrote:

>Jason: you didn't ask directly, but if the working group was polled to
>determine support for adopting this document, I would say yes and
>volunteer to review it.

Thanks, Joe, for prodding me to be more explicit! ;-) Yes, that is indeed
one of my questions: is this an interesting doc to the WG. I also listed
the following open issues in the draft:

1. Determine whether RFC 2119 language should be used or not when
describing things like the duration of a NTA.

2. Determine whether this is an individual I-D or a DNSOP WG I-D.

3. Determine whether this is Informational or a BCP.

4. The DNSOP WG should discuss whether a 1 day limit is reasonable,
whether a different time (more or less than 1 day, such as 1 hour or 1
week) should be specified, or whether no time should be specified (just a
recommendation that it SHOULD generally be limited to X).

5. The DNSOP WG should discuss how to assess when critical DNSSEC
deployment mass has been achieved so that this is no longer a common
practice.

6. Olafur Gudmundsson has suggested that we may want to consider whether a
non validatable RRSIG should be returned or not when a NTA is in place.
This was raised in the context of NLnet Labs' DNSSEC-Trigger, which
apparently acts like forwarding stub-validator. He said, "The reason for
this is if NTA strips signatures the stub-validator thinks it is under
attack and may a) go into recursive mode to try to resolve the domain,
getting to the right answer the long way. b) Give the wrong error "Missing
signatures" instead of the real error. If all the validator does is not to
set the AD bit for RRsets at and below the NTA, stub-resolvers (and
cascading resolvers) should be happy."

- Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 17 Feb 2013 15:18:21 +0000

On 2/16/13 7:43 PM, "Paul Hoffman" <[email-masked]> wrote:

>Ted's misunderstanding of what you are proposing is a valid one. You
>don't actually say what a negative trust anchor is, and what it is a
>trust anchor for, until section 7. Readers such as Ted (and myself!) will
>have strong prejudices by then.

Yeah, I can see why you would say that! I will move Section 7 up in the
doc so that I define a NTA at the top.

>This document discusses trust anchors for DNSSEC. A "negative trust
>anchor" is equivalent to a "regular" DNSSEC trust anchor for a particular
>instance of a recursive validating resolver. A negative trust anchor is
>quite different from regular DNSSEC trust anchors in that they are local,
>temporary, and definitely not distributed by IANA. They are trust anchors
>only for DNSSEC, not for PKIX.

Great feedback! Adding text to the abstract and introduction, and used
much of the text above with a few tweaks (so advise if I've gotten it
wrong once you see it in -04).

Thanks!
Jason

>
>That should help set the tone for the following sections that say how to
>use them, and then the much later sections on what they actually are.
>
>--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Feb 2013 15:19:59 +0000

On Feb 17, 2013, at 9:57 AM, "Livingood, Jason" <[email-masked]>
 wrote:
> any external validation or sourcing for the Negative Trust Anchor(s).

What's local?   How does the local authority know to set a negative trust anchor?   This seems very labor-intensive and failure-prone.   Generally speaking, from what I've heard, when bad DNSSEC configurations happen, there's a back-and-forth with the administrator of the broken zone.   But this is all third-hand, at best--if your experience has been different I would like to hear about it.

> It basically tells the recursive resolver to not perform (skip) DNSSEC

So this is assuming that validation is occurring on a caching resolver run by the provider, and that negative trust anchors simply won't have any effect for hosts that do their own validation?

> Anchor or anything else for that matter.

I think this is wrong: the incidents I've heard of were mistakes, which resulted in teaching moments for the people who made them, which resulted in them learning how to do it right.   It's not like you're going to get a broken zone signature if you are completely ignorant, because if you are completely ignorant you're not going to try to sign the zone.

> relating RFC5280 to this I-D. :-)

It does help--thanks!

> deployment mass has been achieved so that this is no longer a common

Who cares?   If you publish this, you have to assume that whatever you recommend here is going to continue to be used well beyond its intended lifetime.   Of course, e.g. Comcast will do the right thing, but this won't just be used by Comcast.

I think that if you acknowledge that host-resident validating resolvers are not going to support negative trust anchors, this is a non-problem, since the rise of host-resident validating resolvers, which I think is inevitable in the long run, will automatically obsolete this work.

However, if you do decide to rely on this, it's probably worth talking about what that obsolescence path will look like, since an NTA in the provider caching resolver may produce different results on the host-resident validating resolver, as you mention in point 6.

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 17 Feb 2013 15:22:28 +0000

Based on feedback yesterday on the list, I did a quick –04 update, which is now at https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/.

The are seven open issues documented at the end of the I-D. But the most important questions for this WG are:
1 – Is this worth consideration as a WG I-D or should it continue only as an individual I-D?
2 – If the answer to #1 is that it should be a WG I-D, would you like a brief discussion of the open issues at IETF 86?

Thanks!
Jason

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Feb 2013 15:25:41 +0000

> 1 – Is this worth consideration as a WG I-D or should it continue only as an individual I-D?

Yes, wg i-d.

> 2 – If the answer to #1 is that it should be a WG I-D, would you like a brief discussion of the open issues at IETF 86?

No preference, since I have a conflicting session... :}

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 Feb 2013 07:31:30 -0800

> describing things like the duration of a NTA.

I never understood why one would have 2119 language in an operational document that says "here's a good idea for how to help your operations". Well, other than "people have used that language before", which is kinda an addictive response.

> 2. Determine whether this is an individual I-D or a DNSOP WG I-D.

It definitely seems related to DNS operations.

> 3. Determine whether this is Informational or a BCP.

Informational. Given that it is a new proposal, where's the "C"?

> recommendation that it SHOULD generally be limited to X).

Or a different proposal: "Your operations staff needs to determine how long is too long to allow a broken zone that could be also under attack, and how short is too quick for your operations staff to reassess the problem and remove the NTA; pick a value between those two". 

> deployment mass has been achieved so that this is no longer a common

Start by saying "three years" and see what people think.

> cascading resolvers) should be happy."

That sounds right.

--Paul Hoffman

---

From: Joe Abley <[email-masked]>
Date: Sun, 17 Feb 2013 10:35:47 -0500

> any external validation or sourcing for the Negative Trust Anchor(s).

I hear you, but I'm not sure why you think so.

If I was running a farm of validators inside an ISP network and I didn't already have my configuration control centralised and automated, being able to publish a single zone for internal use which encapsulated the policy does not seem like a bad option for keeping them all consistent.

> Anchor or anything else for that matter.

The use case here is not people who have messed up signing their zones publishing an NTA; it's validator operators who need a convenient way to share their validation policy.

So, to spell it out:

 - hopcount.ca's signer explodes (or something else happens such that hopcount.ca is badly signed)
 - since hopcount.ca is such a popular domain for Comcast customers, Comcast DNS engineers take the time to discover that the validation failure for that zone is in fact due to an operational problem and not an attack
 - Comcast adds a hopcount.ca.nta.comcast.com zone, which is signed
 - Comcast's validators pick up the NTA from that zone and configure themselves accordingly

Precisely what mechanism is used for that last part needs discussion, if people think that this kind of NTA distribution mechanism is worth exploring. It could be a crude mechanism like "tail the validation failure log, look up hopcount.ca.nta.comcast.com, if there's something there reconfigure unbound accordingly" or it could be something more integrated with the validator, so that unbound does the same work internally.

Thinking ahead (and making assumptions about how much disgust people are feeling right now at this idea) I'd be in favour of an NTA being encoded with some timers to help ensure that NTAs are temporary.

Joe

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 17 Feb 2013 15:37:34 +0000

Inline below (and some proposed text for you to give feedback on).

- Jason

On 2/17/13 10:19 AM, "Ted Lemon" <[email-masked]> wrote:

>What's local?   How does the local authority know to set a negative trust
>anchor?   

The operator of a recursive resolver that is performing DNSSEC validation
configures this on the local recursive resolver(s) they control/administer.

>This seems very labor-intensive and failure-prone.

It can be labor intensive, but failures in the configuration of the
resolver carries the same risks as any other configuration change. We
partially scripted it since we have found a need to configure NTAs more
than a few times (meaning we don't manually touch each resolver but
setting up and removing the NTA is not automatic based on validation
failures).

>Generally speaking, from what I've heard, when bad DNSSEC configurations
>happen, there's a back-and-forth with the administrator of the broken
>zone.   But this is all third-hand, at best--if your experience has been
>different I would like to hear about it.

Yes, that's pretty much the case. It is a good learning experience for
authoritative administrators. Only in a subset of such failures have we
used a NTA, depending on the circumstances.

>So this is assuming that validation is occurring on a caching resolver
>run by the provider, and that negative trust anchors simply won't have
>any effect for hosts that do their own validation?

I suppose so - it is a policy on a caching resolver, though that could be
operated by an ISP, DNS ASP, or enterprise. So if you have your own
resolver and you are validating then it should not have any effect on you.

>I think this is wrong: the incidents I've heard of were mistakes, which
>resulted in teaching moments for the people who made them, which resulted
>in them learning how to do it right.   It's not like you're going to get
>a broken zone signature if you are completely ignorant, because if you
>are completely ignorant you're not going to try to sign the zone.

They are definitely teachable moments. But a key concern is for the end
users of a validating resolver, who may not know or care about what
validation is and just know that they cannot access some domain. They
blame the operator of the validating resolver (and impose costs upon
them), rather that the authoritative domain. I hope that changes over time.

>Who cares?   

It was a question I received from a few folks in response to earlier
versions, so I thought it worthy of flagging it for a discussion.

>If you publish this, you have to assume that whatever you recommend here
>is going to continue to be used well beyond its intended lifetime.
>Of course, e.g. Comcast will do the right thing, but this won't just be
>used by Comcast.

Understood.

>I think that if you acknowledge that host-resident validating resolvers
>are not going to support negative trust anchors, this is a non-problem,
>since the rise of host-resident validating resolvers, which I think is
>inevitable in the long run, will automatically obsolete this work.

Makes sense to me. So if I added very explicit text to the effect that
"Negative Trust Anchors MUST NOT be used by host-based DNSSEC validating
DNS resolvers; this practice only pertains to network-based DNS recursive
resolvers that multiple hosts query." would that do it?

- Jason

>However, if you do decide to rely on this, it's probably worth talking
>about what that obsolescence path will look like, since an NTA in the
>provider caching resolver may produce different results on the
>host-resident validating resolver, as you mention in point 6.
>
>_______________________________________________
>DNSOP mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dnsop

---

From: Joe Abley <[email-masked]>
Date: Sun, 17 Feb 2013 07:44:20 -0800

> resolvers that multiple hosts query." would that do it?

If there was a way to publish NTAs in the DNS, I would think unbound running on my laptop could behave the same way as unbound running on a stack of servers in a data centre. Whether or not I configure my laptop-resident unbound to look for such NTAs is surely up to me.

I don't really understand the motivation for the MUST NOT above.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Feb 2013 15:48:51 +0000

> - Comcast's validators pick up the NTA from that zone and configure themselves accordingly

Yes.   Although I think you can just sign nta.comcast.com, and have hopcount.ca.nta.comcast.com be some record in that zone, rather than making it an SOA. For extra credit, you could even make it a ZSK that could be used to validate the zone, in cases where the ZSK rollover was flubbed, but the zone is in fact signed and the ZSK it was signed with is known, and known to be good.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Feb 2013 15:54:03 +0000

> them), rather that the authoritative domain. I hope that changes over time.

So maybe a better way to state your point at the top would be that setting up the NTA is something that validating resolver operators do, possibly in cooperation with the operators of the zones requiring the NTA, because this is what's expedient, and NTAs are all about what's expedient.   :)

> resolvers that multiple hosts query." would that do it?

I think that's a valid thing to say, but what I'm more concerned about is specifically saying what would be different in a response from a validating resolver that implements NTAs in the case of a zone with an NTA, versus a caching resolver that does not validate, for the same broken zone.

---

From: Joe Abley <[email-masked]>
Date: Sun, 17 Feb 2013 11:04:12 -0500

On 2013-02-17, at 10:48, Ted Lemon <[email-masked]> wrote:

> Yes.   Although I think you can just sign nta.comcast.com, and have hopcount.ca.nta.comcast.com be some record in that zone, rather than making it an SOA.

Yes, that's the kind of thing I had in mind.

> For extra credit, you could even make it a ZSK that could be used to validate the zone, in cases where the ZSK rollover was flubbed, but the zone is in fact signed and the ZSK it was signed with is known, and known to be good.

That sounds fancy!

Joe

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Feb 2013 16:06:58 +0000

> I don't really understand the motivation for the MUST NOT above.

If this is informational, then it doesn't make sense to say MUST NOT anyway.   I think there could be a debate: is there a way to subscribe my resolver to the ISP's NTA zone, or not?

The advantage of subscribing is that I get information that helps me to deal with brokenness.   The disadvantage is that I am configuring my validating resolver so that a bad guy who works for my ISP could arrange to send me bad data.   I think it would be perfectly fine to just document this issue in the security considerations section.   It's going to require a positive action to configure my host's validating resolver to do this anyway, which most users will not know how to do.   It's also possibly worth mentioning social engineering attacks on the end user as a risk if such a capability is present in a host-based validating resolver.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 Feb 2013 11:32:19 -0800

> resolvers that multiple hosts query." would that do it?

Please: no. If I have local validation turned on for my own host, and there is a site I need to get to but it has broken signatures, I would like a GUI that says "this zone has broken signatures; ignore validation failures for 60 minutes?".

There is no operational difference between a host that validates and a validating recursive resolver that has exactly one customer that is looking at the one broken zone.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Feb 2013 19:50:58 +0000

> Please: no. If I have local validation turned on for my own host, and there is a site I need to get to but it has broken signatures, I would like a GUI that says "this zone has broken signatures; i…

Training users to bypass security.   This is extremely bad security UI design.   MUST NOT level bad.   How does the user distinguish between "attack" and "mistake"?   I don't even know how I would do it, and I have at least some vague understanding of the security model of DNSSEC, which is a genuine rarity.   What's the point of having a validating resolver if validation can be skipped with a click?

Having a configurable negative trust anchor zone isn't as good as having DNSSEC that can be counted on to always be configured correctly, but it's a lot better than a UI like this.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 17 Feb 2013 12:34:21 -0800

> Training users to bypass security.   This is extremely bad security UI design.   MUST NOT level bad.   How does the user distinguish between "attack" and "mistake"?   I don't even know how I would…

Because I am my own operator. Yes, you want to be my nanny; no, I didn't ask you to be.

> Having a configurable negative trust anchor zone isn't as good as having DNSSEC that can be counted on to always be configured correctly, but it's a lot better than a UI like this.

That would work for me too, but not "you're a host, so you cannot use negative trust anchors", which is what Jason's proposed text said.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 17 Feb 2013 22:51:40 +0000

> Because I am my own operator. Yes, you want to be my nanny; no, I didn't ask you to be.

I don't want to be _your_ nanny.   But you are one of the other two dozen people in the world with some inkling of how DNSSEC works.   You aren't the person that I mean to protect when I say this UI MUST NOT happen.

> That would work for me too, but not "you're a host, so you cannot use negative trust anchors", which is what Jason's proposed text said.

Hence the discussion.   But it is worth paying attention to the way that this solution breaks the assumptions of the DNSSEC security model.   In the case of a validating resolver at the ISP level, it doesn't, because if you're trusting a validating resolver without a secure path to it, you're basically just looking for protection against cache spoofing.

If you have a validating resolver on your host, this gives you much stronger security guarantees; if you then enable negative trust anchors from an ISP list, you are back to the external validator level of security, which is a potentially _substantial_ downgrade, depending on what kind of security your provider offers.

---

From: Ralf Weber <[email-masked]>
Date: Mon, 18 Feb 2013 02:59:30 +0000

Moin!

> - Comcast's validators pick up the NTA from that zone and configure themselves accordingly
That sounds like a negative DLV to me. I think DLV was a bad idea and I don't think this is a good idea either when you are crossing organization boundaries. I guess it is ok when used inside a provider as mechanism to distribute NTA, but then it doesn't need be in that document.

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

---

From: Joe Abley <[email-masked]>
Date: Sun, 17 Feb 2013 22:03:59 -0500

> That sounds like a negative DLV to me. I think DLV was a bad idea and I don't think this is a good idea either when you are crossing organization boundaries. I guess it is ok when used inside a pro…

You could compare it to DNS RBLs, too. You don't have to like it for it to exist (you don't have to use it.) It doesn't need to be universally liked to be useful.

I think the problem that validation is expensive to turn on for ISPs (and has value which is difficult to explain to customers) is a real one. I think we want more validation to happen. Making it cheaper to turn on validation seems important.

Joe

---

From: Ralf Weber <[email-masked]>
Date: Mon, 18 Feb 2013 03:19:04 +0000

Moin!

> I think the problem that validation is expensive to turn on for ISPs (and has value which is difficult to explain to customers) is a real one. I think we want more validation to happen. Making it c…
I fully agree on this, which is why I support this draft. However to achieve that goal (making it easier for ISPs to implement DNSSEC) I don't think it is necessary to specify how NTA will be distributed. If you think it is important to have a vendor independent way of distributing NTA this might be a second step, however it's usage should be very limited and not crossing organizational boundaries.

So long
-Ralf
---
Ralf Weber

---

From: Joe Abley <[email-masked]>
Date: Sun, 17 Feb 2013 22:29:02 -0500

Hi Ralf,

> I fully agree on this, which is why I support this draft. However to achieve that goal (making it easier for ISPs to implement DNSSEC) I don't think it is necessary to specify how NTA will be distr…

This is getting a bit tangential, but why is it important for NTA distribution not to cross organisational boundaries?

If a standard distribution mechanism existed, how do you imagine a limited scope could be enforced?

Joe

---

From: Ralf Weber <[email-masked]>
Date: Mon, 18 Feb 2013 03:48:55 +0000

Moin!

> This is getting a bit tangential, but why is it important for NTA distribution not to cross organisational boundaries?
Because I and guess ISPs also don't want somebody to mess with the resolution answers of their resolver. If I screw up I am responsible, but if another third party that probably I don't have a contract with screws up who is responsible. As an admin of DNS Services at an ISP you will get that question if something goes bad, and that is why I didn't like the DLV approach.
 
> If a standard distribution mechanism existed, how do you imagine a limited scope could be enforced?
It probably couldn't as people tend to ignore advices no matter how often you write them down. That's why I think we shouldn't include them in this draft.

So long
-Ralf
---
Ralf Weber

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 18 Feb 2013 10:52:09 -0500

On 17/02/2013 10:22, Livingood, Jason wrote:
> Based on feedback yesterday on the list, I did a quick –04 update, which
> is now at
> https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/.
>
>

If we think this going to be used by many and over a "long" time then 
the answer is yes
If they is just a hack to prevent few DNS resolver operators from 
getting bad press because their operations are slandered by the mistakes 
of a publisher of DNS information the answer is no.

I'm in the first camp, we should document this as BCP.

> 2 – If the answer to #1 is that it should be a WG I-D, would you like a
> brief discussion of the open issues at IETF 86?
>

Yes.

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Mon, 18 Feb 2013 16:57:42 +0100

Jason,

On 17/02/2013 10:22, Livingood, Jason wrote:
>> Based on feedback yesterday on the list, I did a quick –04 update

Personally I would also have changed all references to RFC4641 into RFC6781.

Regards,

--
Marco

---

From: Warren Kumari <[email-masked]>
Date: Mon, 18 Feb 2013 11:28:16 -0500

> 2 – If the answer to #1 is that it should be a WG I-D, would you like a brief discussion of the open issues at IETF 86?

Yes please, to both.
W

--
It's a mistake trying to cheer up camels. You might as well drop meringues into a black hole. -- Terry Prachett

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 18 Feb 2013 19:36:29 +0000

Thanks for catching that - will correct this in -05.

Jason

On 2/18/13 10:57 AM, "Marco Davids (SIDN)" <[email-masked]> wrote:

>>> Based on feedback yesterday on the list, I did a quick 04 update
>

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 18 Feb 2013 15:24:27 -0500

Jason, in section 10 you talk about possible early removal the NTA when 
validation succeeds but there may be instances where validation succeeds 
when using a sub-set of the authoritative servers thus NTA should only 
be removed if all servers are providing "good" signatures.

Furthermore what to do if some names work but others do not, for example 
I remember a case where the records at the apex worked but all names 
below the apex were signed by a key not in the DNSKEY RRset, thus it is 
possible that either human or automated checks may assume there is no 
problem when there actually is one.
What this is bringing to my mind is maybe you want a new section with 
guidelines on how to test for failures and in what cases failure 
justifies NTA and what tests MUST pass before preemttive removal of an NTA.

Also should there be guidance that removal of NTA should include 
cleaning the caches of all RRsets below the name?

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Feb 2013 08:56:27 +1100

> be removed if all servers are providing "good" signatures.

Why?  This is no different to a server being down.  Validators are
expected to ignore bad answers so a conforming resolver will find
the working copies of the zone.
 
> problem when there actually is one.

This is no different than making the decision to add a NTA or not.

> cleaning the caches of all RRsets below the name?

There are lots of ways to stuff up DNSSEC.  There are different steps
that can be taken to cleanup after such stuff ups.  We don't need to
describe those steps.  
 
> > Based on feedback yesterday on the list, I did a quick update, which
> > is now at
> > 
> > 1 * Is this worth consideration as a WG I-D or should it continue only
> > as an individual I-D?
> > 2 * If the answer to #1 is that it should be a WG I-D, would you like a

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Tue, 19 Feb 2013 00:37:32 +0000

Joe Abley <[email-masked]> wrote:
>
> You could compare it to DNS RBLs, too. You don't have to like it for it
> to exist (you don't have to use it.) It doesn't need to be universally
> liked to be useful.

I agree with your point but there is also a difference. RBLs (and DNS
response policy zones) create breakage in order to protect users. NTAs
hide breakage in order to placate users.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 19 Feb 2013 16:21:40 -0500

> That should help set the tone for the following sections that say how to use them, and then the much later sections on what they actually are.

I also think that it would be very helpful to actually show *how* this is used, with e.g and example in an Appendix, for <insert favorite resolver here>.

The document contains a lot of really useful content about why you might use one, how to minimize damage, etc but (IMO) does't do a great job of explaining *how* to actually do so…

But yes, I think it should be considered for adoption / if this is a CfA I support it :-P
I'd also like to see it presented / discussed at the meeting...

W

--
"Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett

---

From: Richard Lamb <[email-masked]>
Date: Wed, 20 Feb 2013 10:50:40 -0800

Jason-

FWIW: The -04 draft looks good.  It is clear and well written and I think it is a valuable resource.
As I am late to looking at this draft please take this only as a comment from a narrow minded engineer ;-)   After the rationale, explanations and caveats I kept looking for how to implement a NTA.  After initially thinking this would be the introduction of some new functionality and RRset manipulation, I only found a reference to how Unbound implements it.
So it might be useful to have section 2 "Definition .." make that clear for slow people like me - that the NTA is not an RR and is more of a configuration.  Maybe simply replacing "placed" with "implemented" in section 2?  "This NTA can potentially be [placed][implemented] at any level within the chain of trust..."
Feel free to ignore of this thread has already been covered.   Regardless of whether my comment makes sense, I do this this is a useful draft to have.

-Rick

From: [email-masked] [mailto:[email-masked]] On Behalf Of Livingood, Jason
Sent: Sunday, February 17, 2013 7:22 AM
To: [email-masked]
Subject: [DNSOP] New draft-livingood-negative-trust-anchors-04

Based on feedback yesterday on the list, I did a quick -04 update, which is now at https://datatracker.ietf.org/doc/draft-livingood-negative-trust-anchors/.

The are seven open issues documented at the end of the I-D. But the most important questions for this WG are:
1 - Is this worth consideration as a WG I-D or should it continue only as an individual I-D?
2 - If the answer to #1 is that it should be a WG I-D, would you like a brief discussion of the open issues at IETF 86?

Thanks!
Jason

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Feb 2013 14:52:15 -0400

On 2013-02-20, at 14:50, Richard Lamb <[email-masked]> wrote:

> As I am late to looking at this draft please take this only as a comment from a narrow minded engineer ;-)   After the rationale, explanations and caveats I kept looking for how to implement a NTA.

+1

The text seems to lead in that direction, and then end abruptly leaving the reader wondering what happened. Leaving room for a sequel? :-)

Joe

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 22 Feb 2013 19:52:21 +0000

Ack. Tracking the need for examples in the open issues log for the I-D.

On 2/19/13 4:21 PM, "Warren Kumari" <[email-masked]> wrote:

>>trust anchor for, until section 7. Readers such as Ted (and myself!)
>>will have strong prejudices by then.
>> 
>>anchor" is equivalent to a "regular" DNSSEC trust anchor for a
>>particular instance of a recursive validating resolver. A negative trust
>>anchor is quite different from regular DNSSEC trust anchors in that they
>>are local, temporary, and definitely not distributed by IANA. They are
>>trust anchors only for DNSSEC, not for PKIX.
>> 
>> That should help set the tone for the following sections that say how
>>to use them, and then the much later sections on what they actually are.
>
>
>I also think that it would be very helpful to actually show *how* this is
>used, with e.g and example in an Appendix, for <insert favorite resolver
>here>.
>
>The document contains a lot of really useful content about why you might
>use one, how to minimize damage, etc but (IMO) does't do a great job of
>explaining *how* to actually do soŠ
>
>"Build a man a fire, and he'll be warm for a day. Set a man on fire, and
>he'll be warm for the rest of his life." -- Terry Pratchett
>
>

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 22 Feb 2013 19:55:45 +0000

On 2/20/13 1:50 PM, "Richard Lamb" <[email-masked]<mailto:[email-masked]>> wrote:
As I am late to looking at this draft please take this only as a comment from a narrow minded engineer ;-)   After the rationale, explanations and caveats I kept looking for how to implement a NTA.  After initially thinking this would be the introduction of some new functionality and RRset manipulation, I only found a reference to how Unbound implements it.
Ack. Warren suggested the same. I will add to open issues in the next update and will add it to a future update of the doc!
So it might be useful to have section 2 “Definition ..” make that clear for slow people like me - that the NTA is not an RR and is more of a configuration.  Maybe simply replacing “placed” with “implemented” in section 2?  “This NTA can potentially be [placed][implemented] at any level within the chain of trust…”
Will do – added this to my open issues tracker as well.

JL

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 22 Feb 2013 20:05:49 +0000

>be removed if all servers are providing "good" signatures.

Excellent point! We have certainly see cases where 2 of 3 name servers are
fine and one of them is acting wonky. I will add that to the open issue
tracker for a future substantive update!

>justifies NTA and what tests MUST pass before preemttive removal of an

Good question - will address in a future version as well.

>cleaning the caches of all RRsets below the name?

I think so, yes. I will add this as well - can't hurt.

Thank you,
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 22 Feb 2013 20:06:13 +0000

On 2/20/13 1:52 PM, "Joe Abley" <[email-masked]> wrote:

>> As I am late to looking at this draft please take this only as a
>>comment from a narrow minded engineer ;-)   After the rationale,
>>explanations and caveats I kept looking for how to implement a NTA.
>
>+1
>
>The text seems to lead in that direction, and then end abruptly leaving
>the reader wondering what happened. Leaving room for a sequel? :-)

Ack - will address in a future rev. :-)

JL

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 22 Feb 2013 20:08:59 +0000

>the working copies of the zone.

I suppose it is sometimes hard to verify - as each auth NS must be
checked. It is a corner case, but seen in the wild. I'll take a stab at
trying to address it, and if you think it goes into too much detail or is
too obvious, please say so. :-)

>> justifies NTA and what tests MUST pass before preemttive removal of an
>> NTA. Also should there be guidance that removal of NTA should include

>that can be taken to cleanup after such stuff ups.  We don't need to

Quite so! I think this can be addressed simply in one or two sentences. If
it seems unnecessary (as above) once I add it, say so.

Thanks!
Jason

---

From: Edward Lewis <[email-masked]>
Date: Thu, 28 Feb 2013 09:22:02 +0800

On Feb 17, 2013, at 23:19, Ted Lemon wrote:

> What's local?

DNSSEC set out to step cache poisoning.  Look at it from the cache's point of view.

Local means "whatever the owner/operator of the cache" controls.  From the time we began to develop validation, decision points were all covered by "local policy rules."

DNSSEC is popularly known by it's supply side activity - how many zones are signed, etc.  But that's a red herring when it comes to what DNSSEC is all about.

So, local is what the operator of the cache (caching server[s]) wants it to be.

> How does the local authority know to set a negative trust anchor?  This seems very labor-intensive and failure-prone.

There is already a commercial market trading on the reputation of domain names.  There are various of commercial sources that will recommend disrupting traffic to and from sources of, say, spam.  This is in addition to the labor intensive process of investigating everything "yourself."

The first step that is needed is to be able to have name servers turn off DNSSEC validation per domain name (=zone at times) and then back on.

The next step is to figure out when should DNSSEC be turned off and on.

The next step is to make this scaleable in some reasonable sense.

I don't know "much" about this, in the sense I haven't been paying close attention.  But I have been surprised to find that there's more progress on the first step that I'd have thought.  I also know there's quite a bit of maturity in the latter two steps.  But just not (the maturity that is) in publicly available documents.

Again, because I haven't actually read the trust-anchors document(*), I can't honestly register support for it but it's probably (or I hope is) a first step into making what's already in play commercially appear in a publicly available document.  (To date I'm just catching up on the mail list thread.)

(*) - From a conversation a decade ago, I've learned it's best to be completely honest about whether you've actually read a document thoroughly when responding to a question from Ted. ;)

Ok, so to be honest I might have read the draft in an earlier form, I certainly don't recall if I did.

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis             
NeuStar                    You can leave a voice message at +1-571-434-5468

There are no answers - just tradeoffs, decisions, and responses.