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

From: Wes Hardaker <[email-masked]>
Date: Tue, 10 Apr 2012 17:11:15 -0700

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

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

LJ> Feel free to share any other questions or feedback.

I too like the idea behind it, and have the following suggestions to
support it:

1) In addition to the following statement:

       Furthermore, a Negative Trust Anchor should
       be used only for a short duration, perhaps for a day or less.

   I'd go ahead and insert MUST/SHOULD/MAY language as well (realizing
   that if there is a document people will ignore it in, this is likely
   to be one).  And then add some timing constraints too [reading the
   rest of the thread after typing this, I note that Shane also
   suggested an end time, but the proposal below also imposes a maximum
   end-time allowable].

   Suggested rewrite:

       Furthermore, a Negative Trust Anchor MUST only be used for a
       short duration, perhaps for a day or less.  Implementations MUST
       require an end-time configuration associated with any negative
       trust anchor.  Implementations SHOULD limit the maximum time into
       the future to one day.  In other words, the configuration
       directive will be invalid if it is missing an end-time or if the
       end time is greater than "now" plus 86400 seconds.

2) I also suggest you rename the concept to "Negative Anchors of Trust"
   and then sprinkle the document with statements like the following:

       NATs are not an appropriate long-term solution and if they need to be
       used, they MUST be used only for short periods of time.

   (it's the two-birds-with-one-stone theory of RFC writing)

-- 
Wes Hardaker
SPARTA, Inc.

---

From: "Griffiths, Chris" <[email-masked]>
Date: Wed, 11 Apr 2012 02:36:59 +0000

>   suggested an end time, but the proposal below also imposes a maximum

Perhaps a TTL equivalent as previously suggested, I agree we should look to add the MUST/SHOUD/MAY language for this.

>       end time is greater than "now" plus 86400 seconds.

Agreed.  Maximum time supported makes sense to me.

>   (it's the two-birds-with-one-stone theory of RFC writing)

I got a good chuckle on this one.  We will have to think hard about this :-)

Thanks

Chris

---

From: Shane Kerr <[email-masked]>
Date: Wed, 11 Apr 2012 13:40:23 +0200

Chris,

On Wednesday, 2012-04-11 02:36:59 +0000,
"Griffiths, Chris" <[email-masked]> wrote:
> >       short duration, perhaps for a day or less.  Implementations
> > MUST require an end-time configuration associated with any negative
> >       trust anchor.  Implementations SHOULD limit the maximum time
> > into the future to one day.  In other words, the configuration
> >       directive will be invalid if it is missing an end-time or if
> > the end time is greater than "now" plus 86400 seconds.
> 

This seems like an unnecessary limitation to me.

For example, I know someone who regularly forgets to re-sign his zones.
Yes, he knows he should set BIND up to re-sign them automatically or
perhaps use zkt, but that takes time and it's just his own vanity
domain. Personally I would like to set a negative trust anchor for his
zones until such time as he sets something like this up, since I know
that the signatures will expire in a few months and break the zone for
me at that time.

Plus, I know it is surprising to folks on this list, but some zones do
not have full time administrators, and may have to wait until admin
staff get back on Monday morning until they are fixed - or perhaps even
until the one "computer guy" at a company gets back from vacation.

I'm just saying, requiring some maximum time makes sense, but
specifying one that works for large, professional ISPs may not work for
everyone. Can we just keep it open?

--
Shane

---

From: Ralf Weber <[email-masked]>
Date: Wed, 11 Apr 2012 13:02:08 +0000

Moin!

>       end time is greater than "now" plus 86400 seconds.

I disagree with that. I have seen misconfigured domains that where misconfigured on error for a much longer time. Also process wise if the negative trust anchors automatically get removed from the server and the domain is still misconfigured it will go off again for the resolver operators customers. The addition and the removal of a negative trust anchor should be a process in the operators network and not an automation in software.

>       used, they MUST be used only for short periods of time.

Again I have a problem with the MUST. As above it should be a SHOULD.

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

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 11 Apr 2012 06:28:49 -0700

> I disagree with that. I have seen misconfigured domains that where misconfigured on error for a much longer time. Also process wise if the negative trust anchors automatically get removed from the…

Two comments:

a)  If end-time is specified as a date, not an interval, you can set the date to be 'end of epoch', so you can basically have it 'stay forever', even if thats not advised: which would make me think the proper approach is 'it SHOULD/MUST be a warning when a negative trust anchor with duration longer than 1 day from current time is installed", but allow it to be installed.

If an option allows someone to really shoot themselves in the foot, and a >1 week negative trust anchor should probably be considered that, even if allowable it should be warned.

b)  Actually, I think it should also be auto removed once the condition is fixed:  Continue to attempt to validate the zone in question.  When the zone validates again, the default behavior should be to automatically remove the negative trust anchor.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Apr 2012 15:16:25 +0100

Griffiths, Chris <[email-masked]> wrote:
> >       short duration, perhaps for a day or less.
>

This only makes sense if the negative trust anchor is for a third party
domain. There are situations where it makes sense to use negative trust
anchors covering your own domains, and these might be necessary for a
long period of time (because that would require a difficult upgrade or
extensive renaming). There are more use cases than just the NASA screwup
scenario.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Shannon, Southwest Rockall: Northwesterly 5 or 6. Rough or very rough. Rain or
showers. Moderate or good.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Apr 2012 15:20:50 +0100

> For example, I know someone who regularly forgets to re-sign his zones.

That's just stupid. There are a lot of sensible words in Jason's draft
to say that negative trust anchors should not be used as a long-term
workaround for some third party's persistent incompetence.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Trafalgar: Northwest 3 or 4, increasing 5 or 6. Moderate or rough, but slight
in far south for a time. Occasional rain. Moderate or good, occasionally poor
later.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 11 Apr 2012 16:33:11 +0200

Nicholas,

On Wednesday, 2012-04-11 06:28:49 -0700,
Nicholas Weaver <[email-masked]> wrote:
> b)  Actually, I think it should also be auto removed once the
> condition is fixed:  Continue to attempt to validate the zone in
> question.  When the zone validates again, the default behavior should
> be to automatically remove the negative trust anchor.

That's a very good idea, at least as an option. (I know some
administrators never want anything to happen automatically. Some people
love extra work, or at least are paranoid about computers getting stuff
wrong.)

--
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 11 Apr 2012 16:48:20 +0200

Tony,

On Wednesday, 2012-04-11 15:20:50 +0100,
> workaround for some third party's persistent incompetence.

Okay, that was an extreme example, but nevertheless if your customers
want service to a domain that works if DNSSEC is disabled, what choice
do you have?

What the ISP experiences:

	Customer: "I can't get to supercute.newtld!!!! WHINE!!!"
	ISP:      "Yes, sorry, they have a technical problem with
		  their domain and it is not secure."
	Customer: "But it works from the office!!!"
	ISP:      "Your office does not have DNSSEC validation
		  enabled, and is not protecting you."
	Customer: "You suck! I'm going to EvilCompetitor, Inc.!!!"

What the customer experiences:

	Customer: "Sorry to disturb you, but my most loved people in
	          the world can't get to the one web site that
	          brings joy into their lives."
	ISP:      "The dilithium crystals in the Heisenberg
	          compensators of that PADD are misaligned."
        Customer: "Okay... but I tried it from work and it is okay."
        ISP:      "HAHAHA!! Trust us, we know what we're talking about
                  and nobody else does. You can't really see this site
                  from work, it is an evil impostor!!!"
	Customer: "Riiiight..."

Disabling DNSSEC validation for broken domains seems completely
rational, at least for some types of brokenness.

--
Shane

---

From: Jim Reid <[email-masked]>
Date: Wed, 11 Apr 2012 15:59:34 +0100

> rational, at least for some types of brokenness.

+1

The problem here is this becomes a local policy/configuration matter  
and the experience you outlined still occurs Shane. Sometimes things  
will work (for some definition of work) even if DNSSEC validation  
fails, sometimes they won't. I don't see any easy answers. It would be  
nice if browsers (say) popped up a dialogue box which said "I'm not  
sure about this IP address, do you feel lucky?" when a validation  
failed so the end user could decide how to proceed. But this would be  
unpopular and almost certainly get ignored or switched off. And of  
course it does nothing for all the other application software that  
might like to know if they're handling validated DNS data or not.

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Apr 2012 16:21:31 +0100

> > rational, at least for some types of brokenness.

I agree, and this is what the draft says. I suppose this sub-argument is
over where to draw the line, which indicates to me that the draft should
not go into detail about policy since this will depend a lot on the
relative bloody-mindedness of operators and their user bases.

Tony.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Apr 2012 09:09:15 -0700

>>>>> On Wed, 11 Apr 2012 06:28:49 -0700, Nicholas Weaver <[email-masked]> said:

NW> a) If end-time is specified as a date, not an interval, you can set
NW> the date to be 'end of epoch', so you can basically have it 'stay
NW> forever', even if thats not advised

That's why I suggested the upper limit, and the config would need to be
time based.  IE:

  NTA example.com Thu Apr 12 09:06:42 PDT 2012

Note that if you really need to keep some trust anchors around for a
long time, it's still very hackable via a cron script:

  rm /etc/long-ntas.conf
  for i in example.com other.example.com ; do
     echo "NTA $i `date -d '+1 day'`" >> /etc/long-ntas.conf
  done
  # restart/reconf/etc here

[btw, I said "one day" based on the original wording in the draft that
implied that was a reasonable upper limit.  I'm not sure that one day is
the right period actually]

[btw2, I'd expect many (most?) implementations to ignore the SHOULD :-( ]
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 11 Apr 2012 09:14:27 -0700

>>>>> On Wed, 11 Apr 2012 13:40:23 +0200, Shane Kerr <[email-masked]> said:

SK> For example, I know someone who regularly forgets to re-sign his zones.
SK> Yes, he knows he should set BIND up to re-sign them automatically or
SK> perhaps use zkt, but that takes time and it's just his own vanity
SK> domain. Personally I would like to set a negative trust anchor for his
SK> zones until such time as he sets something like this up, since I know
SK> that the signatures will expire in a few months and break the zone for
SK> me at that time.

I'm sure ISC could stand up a helpful service to the world called DLNV
that could keep your friends zone permanently registered in it.

If we're going down the broken-trust-anchor road, we might as well
consider a dynamic-lookup mechanism.  You know it's coming.

SK> Plus, I know it is surprising to folks on this list, but some zones do
SK> not have full time administrators, and may have to wait until admin
SK> staff get back on Monday morning until they are fixed - or perhaps even
SK> until the one "computer guy" at a company gets back from vacation.

I'm not sure that installing a permanent "don't ever validate this"
configuration token is a good thing for that situation.  If a zone is
signed and fails validation because of lack of responsibility then the
zone needs to be broken.  We don't, for example, provide a "for this
zone, the real name servers are actually somewhere.else.example.com
because the zone operator is on vacation and didn't update the
registry".  We could.  We could offer "use this instead for A, AAAA, MX,
DS, ...".  A slippery slope this way comes.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Apr 2012 09:56:13 -0700

>  NTA example.com Thu Apr 12 09:06:42 PDT 2012

I realise this is just a thought experiment, but if there are dates to be specified in the presentation of new RRs then they should probably be in the same format as those used in RRSIGs. I would have liked to say RFC3339, but consistency with the rest of the DNSSEC spec (which unfortunately did not use 3339) is probably more important.

I agree that negative trust anchors ideally need an expiration date.

I confess I have not been following this thread very closely, and the discussion of resource records seems like something that has arisen outside the text being reviewed. I presume that someone has had the idea is to publish an NTA (or whatever) in a lookaside zone that a resolver could be configured to use, rather than in a parent zone (since a parent could just remove a DS RRSet). Such a lookaside zone could be provisioned using dynamic updates or static data or whatever suits the administrator.

If negative trust anchors (or, more generally, signalling to instruct a validator to ignore a bad signature) is to be published in the DNS, then the NTA (or whatever) records SHOULD be signed such that a relying validator can trust the signalling.

From the point of view of troubleshooting, it'd also be nice to have the option of encoding a reason (e.g. so that NTAs left in a zone beyond their expiry could be viewed by others for diagnostic purposes). And if there was an inception date also specified, that would surely also help.

; Hopcount's resolvers are configured to look for NTAs in the zone nta.hopcount.ca.
$ORIGIN nta.hopcount.ca.

; example.com's DNSSEC is broken, let's not use it for a day
example.com NTA 20120412162716 20120411162716 "ticket [HOPCOUNT-12345] [email-masked]"
example.com RRSIG ...

I might also wonder whether such a record might usefully be returned in the additional section of a response that is a result of a signature being ignored. This would allow a stub resolver to tell that signatures are being deliberately ignored by the validator, without having to know explicitly what lookaside zone the validator is using.

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45786
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com. IN SOA

;; ANSWER SECTION:
example.com. 3462 IN SOA dns1.icann.org. hostmaster.icann.org. 2011063333 7200 3600 1209600 3600

;; ADDITIONAL SECTION:
example.com.nta.hopcount.ca. 3462 IN NTA 20120412162716 20120411162716 "ticket [HOPCOUNT-12345] [email-masked]"

Joe

---

From: Dr Eberhard Lisse <[email-masked]>
Date: Wed, 11 Apr 2012 18:45:12 +0100

Joe

on 2012-04-11 17:56 Joe Abley said the following:
[...]
> example.com NTA 20120412162716 20120411162716 "ticket [HOPCOUNT-12345] [email-masked]"
[...]

just a tiny nit to pick, would not the '@' in [email-masked]' be
substituted by the "origin" when you dig this? :-)-O

el

-- 
Dr. Eberhard W. Lisse  \        / Obstetrician & Gynaecologist (Saar)
[email-masked] el108-ARIN / *     |   Telephone: +264 81 124 6733 (cell)
PO Box 8421             \     /   Please do NOT email to this address
Bachbrecht, Namibia     ;____/        if it is DNS related in ANY way

---

From: Joe Abley <[email-masked]>
Date: Wed, 11 Apr 2012 10:53:45 -0700

Dr Lisse,

> substituted by the "origin" when you dig this? :-)-O

That depends on how you define the RDATA for NTA. Let's say "no". :-)

Joe

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Apr 2012 14:00:06 -0400 (EDT)

> rational, at least for some types of brokenness.

So someone will make a browser plugin to enable this. Let them.

Paul

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 12 Apr 2012 09:23:37 -0700

Joe Abley <[email-masked]> writes:

> I realise this is just a thought experiment

Well, true it certainly is.  And in fact the above thought experiment
wasn't meant to imply a resource record, but rather a config line.  I
should have probably written it like this:

    NTA {
      example.com Thu Apr 12 09:06:42 PDT 2012;
    };

Or something.  In actuality, I'd expect every implementation to have a
different config file structure of couse.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 12 Apr 2012 09:24:22 -0700

> So someone will make a browser plugin to enable this. Let them.

In our validation work within firefox we deliberately did *not* put in a
"continue anyway" button.
-- 
Wes Hardaker
SPARTA, Inc.

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 16 Apr 2012 17:52:29 +0000

Inline

>extensive renaming). There are more use cases than just the NASA screwup

True. We had an issue with one of our own domains that has persisted
longer. So I think this argues agains an maximum duration for all NTAs,
and simply some TTL that the DNS admin can set (which could vary by
domain). The other alternative is to leave this question completely to
implementers, where some will set a max duration for all NTAs, others will
choose a TTL that varies by domain, and others still may not specify any
times (in force until removed).

Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Mon, 16 Apr 2012 17:55:39 +0000

>wasn't meant to imply a resource record, but rather a config line.

+1

> I
>different config file structure of course.

This is my expectation as well - it is a config file implemented by a DNS
administrator (on a recursive resolver).

- Jason

---

From: "Griffiths, Chris" <[email-masked]>
Date: Tue, 17 Apr 2012 19:26:56 +0000

> times (in force until removed).

I think leaving flexibility to support different use cases makes sense, since there are definitely going to be different reasons for keeping an NTA in place for short as well as longer term reason.  Perhaps we can define these additional use cases like short term, longer term, and indefinite until removed.

Chris