Subject: [DNSOP] Alissa Cooper's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 08 Jul 2015 15:54:00 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-dnsop-negative-trust-anchors-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

= Sec 2 =

"Technical personnel trained in the operation of DNS servers MUST
   confirm that a failure is due to misconfiguration"

s/MUST/must/ - seems odd to put a normative requirement on people to do
something in people land

= Sec 4 =

"The lifetime MUST NOT exceed a week. "

Would be good to provide the motivation for where this number comes from.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 8 Jul 2015 21:50:09 -0400

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/

Fair 'nuff. We had some discussions on this, but there wasn't really
any strong consensus.
I've made the edit and posted in Github -
https://github.com/wkumari/draft-livingood-dnsop-negative-trust-anchors

> Would be good to provide the motivation for where this number comes from.

This number comes from Evan.... :-)

Less flippantly, it is in this email:
https://www.ietf.org/mail-archive/web/dnsop/current/msg13004.html  I
don't think that we have a really good motivation for a week, other
than that is feels sort of like a good, human scale timeframe to
recheck on things. We really want there to be a limit on the lifetime,
a week felt right... but, I still like "because Evan said so..."

Are you OK with leaving it unmotivated[0], because there isn't really
a good motivation?

W
[0]: :-)

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

---

From: Evan Hunt <[email-masked]>
Date: Thu, 9 Jul 2015 03:11:14 +0000

On Wed, Jul 08, 2015 at 09:50:09PM -0400, Warren Kumari wrote:
> a week felt right...

Yep, that's pretty much it, right there.  A day isn't enough (we had
feedback from customers to this effect) but anything longer than a week
strikes me as much too likely to fall off operators' radar.  Though the
limit is arbitrary, I do believe that we need to assert *some* limit,
on this approximate time scale.

> but, I still like "because Evan said so..."

Yes let's definitely document it that way. "... MUST NOT exceed a week,
due to the whimsical and capricious nature of Evan.  Pray he does not
alter the deal any further."

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 09 Jul 2015 09:58:38 +0200

> Are you OK with leaving it unmotivated[0], because there isn't really

RFC 1035 considers in Section 7.3 that a week for a TTL is excessive.
So you might use that as a (weak) guideline.

	jaap

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 9 Jul 2015 09:23:46 -0400

(No hats, and no strong feelings-- a minor point.)

> on this approximate time scale.

OK, so….vendor feedback from customers sounds like a motivation that's perfectly appropriate to document. "There's limited experience with what this value should be, but at least one large vendor has documented customer feedback suggesting that a week is reasonable based on expectations of how long failures take to fix or to be forgotten. Operational experience may further refine these expectations." 

Agreed that there MUST be an expiration set (Sec. 2) but MUST (or even MUST NOT) always seems weird to me on a specific value, especially given that there's a SHOULD in Sec. 2 about letting the operator set the duration. 

How about: "NTAs MUST expire automatically when their configured lifetime ends.  The lifetime SHOULD NOT exceed a week."

This allows for enforcement in code if Evan wants, without requiring it. :-)

Suzanne

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 9 Jul 2015 11:29:11 -0400

On Thu, Jul 9, 2015 at 9:23 AM, Suzanne Woolf <[email-masked]>
wrote:

> OK, so….vendor feedback from customers sounds like a motivation that's
> perfectly appropriate to document. "There's limited experience with what
> this value should be, but at least one large vendor has documented customer
> feedback suggesting that a week is reasonable based on expectations of how
> long failures take to fix or to be forgotten. Operational experience may
> further refine these expectations."
>
> Agreed that there MUST be an expiration set (Sec. 2) but MUST (or even
> MUST NOT) always seems weird to me on a specific value, especially given
> that there's a SHOULD in Sec. 2 about letting the operator set the duration.
>
> How about: "NTAs MUST expire automatically when their configured lifetime
> ends.  The lifetime SHOULD NOT exceed a week."
>
Strictly speaking the minimum time needed for a Negative Trust anchor is
something like
Domain_Operator_reaction_time + Parent_reaction_time + Parent DS TTL +
DNSKEY TTL

We do not know how long the reaction times are for either the domain
operator nor the Parent, once both have acted we the change is still
hostage of the TTL values selected by the two operators.

>From a large sample of DNSKEY and DS I have (few months old) majority of
parents set DS TTL to a day or more.
Com./net./org/info/root are 1D.
fr./ovh. are 2D

Thus if a domain in fr. requires a negative trust anchor the MINIMAL time
needed for that trust anchor is 3 days.
On the other hand a domain in com.br  is a day.

Summary: giving out a general conservative rule is OK, as predicting the
the total recovery time is impossible as only the lower bound can be
estimated.

Olafur

---

From: Evan Hunt <[email-masked]>
Date: Thu, 9 Jul 2015 15:56:04 +0000

> Domain_Operator_reaction_time + Parent_reaction_time + Parent DS TTL +

Valid point. When the NTA for a name expires, the cached data at and below
that name can also be discarded, so TTLs aren't a major concern when the
cache and the validator are coresident, and it hasn't been a factor with
BIND.  But if validating forwarders and stubs support NTAs they may have
a different experience.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 13 Jul 2015 18:53:30 +0000

On 7/9/15, 11:56 AM, "Evan Hunt" <[email-masked]> wrote:
>Valid point. When the NTA for a name expires, the cached data at and
>below that name can also be discarded, so TTLs aren't a major concern
>when the cache and the validator are coresident,

Yeah, in my experience when we remove a NTA we do a cache flush for that
zone at the same time. But it is all highly variable based on the
situation. I think mandating a max time for a NTA gives us the illusion of
control when the reality is that some judgement tends to be required in
this and many other operational matters. Such is life. ;-)

- Jason