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

From: [email-masked]
Date: Fri, 08 Jul 2016 15:30:44 -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 of the IETF.

        Title           : Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)
        Authors         : Duane Wessels
                          Warren Kumari
                          Paul Hoffman
	Filename        : draft-ietf-dnsop-edns-key-tag-02.txt
	Pages           : 13
	Date            : 2016-07-08

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 two different
   ways for validating resolvers to signal to a server which keys are
   referenced in their chain-of-trust.  The data from such signaling
   allow zone administrators to monitor the progress of rollovers in a
   DNSSEC-signed zone.

   This document describes two independent methods for validating
   resolvers to publish their referenced keys: an EDNS option and a
   differnt DNS query.  The reason there are two methods instead of one
   is some people see significant problems with each method.  Having two
   methods is clearly worse than having just one, but it is probably
   better for the Internet than having no way to gain the information
   from the resolvers.

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-edns-key-tag-02

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: "Paul Hoffman" <[email-masked]>
Date: Fri, 08 Jul 2016 15:36:42 -0700

Greetings again; I'm the new co-author on this draft. Based on the WG 
discussion where a bunch of us wanted to use EDNS0 and a bunch of us 
wanted to use queries, the authors tentatively decided that the best way 
to go forwards is to put both methods in the draft. After all, a 
motivated observer of the signals will not have much problem watching 
both types of signals, and end systems can decide which of the two they 
want to use.

We understand that "specify more than one" is often an unpopular choice 
in the IETF, about as unpopular as "don't get consensus on one". This is 
a WG document so we need consensus even to go with two ways. We look 
forward to hearing from you about this choice and how we can move 
forwards.

--Paul Hoffman

On 8 Jul 2016, at 15:30, [email-masked] wrote:

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

---

From: Bob Harold <[email-masked]>
Date: Mon, 11 Jul 2016 10:50:19 -0400

On Fri, Jul 8, 2016 at 6:36 PM, Paul Hoffman <[email-masked]> wrote:

> discussion where a bunch of us wanted to use EDNS0 and a bunch of us wanted
> to use queries, the authors tentatively decided that the best way to go
> forwards is to put both methods in the draft. After all, a motivated
> observer of the signals will not have much problem watching both types of
> signals, and end systems can decide which of the two they want to use.
>
> We understand that "specify more than one" is often an unpopular choice in
> the IETF, about as unpopular as "don't get consensus on one". This is a WG
> document so we need consensus even to go with two ways. We look forward to
> hearing from you about this choice and how we can move forwards.
>
> --Paul Hoffman
>
>
>
Abstract, second paragraph
"differnt" -> "different"

5.1. Query Format
What if the key tag is less than 0x1000 hex or 4096 decimal - Should the
resulting hex have leading zeros (always 4 characters?) or not?
For example, would 4095 decimal be _ta-0fff or _ta-fff  ?  (I prefer always
4 characters hex, but it is your doc.)

5.3.1. Interaction With Aggressive Negative Caching
I would prefer that the tags always be sorted.  No big deal for two tags,
but if there was a compromise or mistake during a rollover, there might be
three keys and the savings in records might be significant.  If you decide
to specify sorting, I think it would go in section 5.1 and not in 5.3.1.

-- 
Bob Harold

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 14 Jul 2016 19:02:02 -0700

> 4 characters hex, but it is your doc.)

It is a WG doc, not our doc. Do others have a preference on this?

> to specify sorting, I think it would go in section 5.1 and not in 

Would the "savings in records" really be significant? The problems 
caused by people not consistently sorting could make things worse, not 
better. Related: there might be other reasons for three tags, such as 
during an algorithm rollover.

--Paul Hoffman

---

From: tjw ietf <[email-masked]>
Date: Fri, 15 Jul 2016 00:10:49 -0400

(speaking for myself only)

In 5.1, I would think that I'd prefer a standard size, but that doesn't
mean I should rely on it.

For the moment on 5.3.1 . Maybe some text that "an implementer SHOULD sort
their tags" but that mean that one can expect them that way.

tim

On Thu, Jul 14, 2016 at 10:02 PM, Paul Hoffman <[email-masked]>
wrote:

> Would the "savings in records" really be significant? The problems caused
> by people not consistently sorting could make things worse, not better.
> Related: there might be other reasons for three tags, such as during an
> algorithm rollover.
>
> --Paul Hoffman
>
>