Subject: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-05.txt

From: [email-masked]
Date: Tue, 05 May 2015 14:03:09 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : Definition and Use of DNSSEC Negative Trust Anchors
        Authors         : Paul Ebersman
                          Chris Griffiths
                          Warren Kumari
                          Jason Livingood
                          Ralf Weber
	Filename        : draft-ietf-dnsop-negative-trust-anchors-05.txt
	Pages           : 16
	Date            : 2015-05-05

Abstract:
   DNS Security Extensions (DNSSEC) is now entering widespread
   deployment.  However, domain signing tools and processes are not yet
   as mature and reliable as those for non-DNSSEC-related domain
   administration tools and processes.  Negative Trust Anchors
   (described in this document) can be used to mitigate DNSSEC
   validation failures.

   [RFC Editor: Please remove this before publication.  This document is
   being stored in github at https://github.com/wkumari/draft-livingood-
   dnsop-negative-trust-anchors . Authors accept pull requests, and keep
   the latest (edit buffer) versions there, so commenters can follow
   along at home.]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-negative-trust-anchors-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Tony Finch <[email-masked]>
Date: Wed, 6 May 2015 13:37:25 +0100

I have read through the draft. Looks good.

Some wording suggestions:

Section 1.1:

   By way
   of analogy, negative trust anchors stop validation of the
   authentication chain.  Instead, the resolver sends the response as if
   the zone is unsigned and does not set the AD bit.

I suggest:

   Instead, the validator treats any upstream responses as if
   the zone is unsigned and does not set the AD bit in responses it sends
   to clients.

Section 1.2:

   As domains transition to DNSSEC, the most
   likely reason for a validation failure will be misconfiguration.

I suggest:

   As domains transition to DNSSEC, the most
   common reason for a validation failure has been misconfiguration.

I am also worried about DNSSEC failures resulting from botched changes of
domain hosting or ownership. Not sure what to say about that.

Section 2:

The requirement MUST NOT affect parental domains is fine, but why only
SHOULD NOT for other branches of the tree? I would expect that to be MUST
NOT as well. Is this to allow for someone putting an NTA on a DLV domain
perhaps?

I don't understand the diagram :-(

Section 3:

   Most current implementations of DNS validating resolvers currently
   follow [RFC4033] on defining the implementation of Trust Anchor as
   either using Delegation Signer (DS), Key Signing Key (KSK), or Zone
   Signing Key (ZSK).

I suggest:

   Most current implementations of DNS validating resolvers currently
   follow [RFC4033] on configuring a Trust Anchor using either a public
   key as in a DNSKEY RR or a hash of a public key as in a DS RR.

... because this is closer to what RFC 4033 says, and from the point of
view of the validator there's no difference between a KSK and ZSK, and
usual practice says you should only use SEP keys (i.e. KSKs) for trust
anchors so mentioning ZSKs here is very unwise.

This sentence is unclear:

   A Negative Trust Anchor should use domain name
   formatting that signifies where in a delegation a validation process
   should be stopped.

Does it mean:

   A Negative Trust Anchor should be configured using a
   fully-qualified domain name in RFC 1035 master file syntax, to
   indicate that validation should not occur at or below that domain name.

And for:

   Different DNS recursive resolvers may have different configuration
   names for a Negative Trust Anchor.  For example, Unbound calls their
   configuration "domain-insecure."[Unbound-Configuration]

I suggest:

   Different DNS validators may have different configuration
   names for a Negative Trust Anchor.  For examples see Appendix A.

Section A.1:

Worth mentioning unbound-control insecure_add and insecure_remove?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Hebrides, Bailey: Northerly backing northwesterly 6 to gale 8, increasing
severe gale 9 at times, decreasing 5 later in west Bailey. Rough or very
rough, occasionally high in Hebrides. Occasional rain. Good, occasionally
poor.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 8 May 2015 02:41:29 -0400

[ Top post ]

Thanks for all the comments. I've integrated most of them (need
additional text for one), and am posting a new version with the
changes.

Comments inline.

>    the zone is unsigned and does not set the AD bit in responses it sends

DONE.
Thanks.

>    common reason for a validation failure has been misconfiguration.

DONE.
Thanks.

> domain hosting or ownership. Not sure what to say about that.

Me neither -- but that's a type of misconfiguration? :-) If anyone has
suggested test I'm happy to consider it.

> NOT as well. Is this to allow for someone putting an NTA on a DLV domain

I seem to remember it being something subtle to do with delegations,
but will check with co-authors / go back through earlier mail.
Example.com uses ns1.example.net. example.net borks their keyroll, and
we "rescue" them by putting in an NTA. This has affected something in
another branch of the tree.

> I don't understand the diagram :-(

Fair enough - it *is* confusing. I'll ask one of the other authors to
fix it (you *so* don't want me to fix it :-))

> anchors so mentioning ZSKs here is very unwise.

DONE.
Fair 'nuff.

>    formatting that signifies where in a delegation a validation process

Yes, that is unclear....

>    indicate that validation should not occur at or below that domain name.

DONE.
Nope. I don't think that we need to define the format here -- it is
(IMO) an implementation detail.
I don't really know what the point of the sentence is, but it does't
(AFAICT) add anything, and so I'm removing it...
Thanks!

>    names for a Negative Trust Anchor.  For examples see Appendix A.

DONE.
Thanks, much better. That was left over from earlier versions...

> Worth mentioning unbound-control insecure_add and insecure_remove?

NOT DONE.
Yes, yes it is. I believe one of the Unbound developers was going to
contribute text, I'll follow up with them.

Thanks again,
W

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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: Warren Kumari <[email-masked]>
Date: Sat, 9 May 2015 09:43:55 +0200

> fix it (you *so* don't want me to fix it :-))

So, I've chatted with some of the other authors (Paul and Jason) and
we agree that:
A: the diagram is confusing and
B: it doesn't actually *add* anything to the document.

So, we are proposing simply removing it. If anyone screams we'll put it back...

Seem good?
W