Subject: [DNSOP] I-D Action: draft-ietf-dnsop-edns-key-tag-00.txt

From: [email-masked]
Date: Wed, 09 Dec 2015 12:27:33 -0800

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           : The EDNS Key Tag Option
        Author          : Duane Wessels
	Filename        : draft-ietf-dnsop-edns-key-tag-00.txt
	Pages           : 9
	Date            : 2015-12-09

Abstract:
   The DNS Security Extensions (DNSSEC) were developed to provide origin
   authentication and integrity protection for DNS data by using digital
   signatures.  These digital signatures can be verified by building a
   chain-of-trust starting from a trust anchor and proceeding down to a
   particular node in the DNS.  This document specifies a way for
   validating end-system resolvers to signal to a server which keys are
   referenced in their chain-of-trust.  The extensions allow zone
   administrators to monitor the progress of rollovers in a DNSSEC-
   signed zone.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-key-tag/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-edns-key-tag-00

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: Bob Harold <[email-masked]>
Date: Thu, 10 Dec 2015 13:13:09 -0500

> ftp://ftp.ietf.org/internet-drafts/

5.2.1 <https://tools.ietf.org/html/draft-ietf-dnsop-edns-key-tag-00#section-5.2.1>.
Validating Recursive Resolvers

This sentence concerns me:

"When the recursive server

   receives a query with the option set, the recursive server SHOULD set
   the edns-key-tag list for any outgoing iterative queries for that
   resolution chain to a union of the stub client's Key Tag(s) and the

   validating recursive resolver's Key Tag(s)."

That approach hides the fact that the stub client's Key Tag(s) might be
missing the latest tags, which is precisely the information that we are
trying to gather.  The intersection (only tags in all lists) would be a
better indicator of what tags everyone can use to validate.  Better yet
would be to forward multiple lists of keytags (either encoded in one
option, or repeated options) so that the receiver gets a better picture of
all the resolvers and their state.  I would suggest that the recursive
server's tag list be the last list, since that information might be useful
to the receiver.

---

From: Edward Lewis <[email-masked]>
Date: Thu, 10 Dec 2015 20:06:58 +0000

On 12/10/15, 13:13, "DNSOP on behalf of Bob Harold" <[email-masked]
on behalf of [email-masked]> wrote:

> that information might be useful to the receiver.

This raises a good point to me.  As someone who will be in the position of
making use of such data (if available), what will I be doing with it, what
granularity is needed?

The receiver of this (the trust anchor operator) is not going to be able to
really act on the information in the sense of fixing "broken" applications.
I mean, if an IP address tells me they don't have my latest trust anchor,
I'm not about to get into a conversation (packet exchange) with them to get
them up to date.

I'm never going to be able to see this as 100% adoption either.  Because
once I put a candidate trust anchor up and being to count the 30 days, there
will always be someone "starting life" with RFC 5011.  The first time a 5011
adherent sees the key might be the 29th day I have it out there.  (Whether
or not such a case is "valid" within 5011's model is another matter
entirely.  Perhaps a validator starting life will have to consult some other
way to get to an initial state of security and that other way may already
declare the candidate to be full-fleldged.  Well, then they'll already list
the key tag.  Hmmm.)

I don't know if there's need to aggregate.  EDNS0 is hop-by-hop and I can't
see that trying to fight its nature will give us a benefit that overcomes
the cost of "tunneling" information through the hops.  If a validating IP
address has to go though a forwarder (in a captive network), what trust
anchors it has isn't really useful to the receiver of the option.

My sense is that when I look at the responses, I'll get a sense of how many
IP addresses hitting my servers have the candidate trust anchor and I can
make a decision to roll.  If I just know about the IP addresses that hit me,
I think that's probably sufficient.  (Am I wrong?)