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

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 10 Aug 2016 16:54:39 -0700

[[ A month later, we're still eager to hear responses to the draft. We 
got a few that we have incorporated for a new version, but want to be 
sure we're on the right track before we move ahead. ]]

On 8 Jul 2016, at 15:36, Paul Hoffman wrote:

> 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:
>
>> 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/
>>
>> _______________________________________________
>> DNSOP mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dnsop
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: 神明達哉 <[email-masked]>
Date: Fri, 19 Aug 2016 11:38:15 -0700

At Wed, 10 Aug 2016 16:54:39 -0700,

> > ways. We look forward to hearing from you about this choice and how we

On this specific point I don't have a strong opinion.  Personally, I
can live with the two-solution approach if it's deemed to be nearly
impossible to reach consensus on a single solution.  While I'd
definitely prefer a single solution, the current draft seems to
provide a reasonable explanation on why we have two at least for now.

Some specific comments on the 02 version follows:

- Section 1.1 (or for general discussion): another obvious downside of
  the QNAME-based approach is that it can't be used for all possible
  zone names because of the size limitation (255 octets) while adding
  extra label.  In practice, this is less likely to be a real issue
  since trust anchors would only be configured a higher level zones.
  But I think it's worth mentioning explicitly.

- Section 4.3

   A responder MUST NOT include the edns-key-tag option in any DNS
   response.

  I wonder whether it might be useful for a responder to signal its
  capability of understanding the option, either by including this
  option in the response or in some other way.  Then the resolver may
  use that information to suppress further unnecessary generation and
  inclusion of the key-tag option.  Not a strong opinion, but raising
  it just in case it's worth considering.

- Section 5.3

   Unless the zone operator has intentionally added
   "_ta-xxxx" records to the zone, the server MUST generate an NXDOMAIN
   response.

  Perhaps a pedantic comment, but I suspect this is not 100% accurate
  in that it could legitimately result in other response than
  NXDOMAIN, e.g., if there's a wildcard that would match the
  "_ta_xxxx" name even if (a record of) that specific name itself
  isn't added to the zone.  On the other hand, ignoring this
  nitpicking this requirement seems to be too obvious; if a name
  really doesn't exist in the zone, the server MUST surely return an
  NXDOMAIN, but it's not specific to this protocol, right?  So, in the
  end, I'd primarily suggest just removing this sentence.  Then we
  don't have to worry about making it very accurate, while IMO not
  leaving any obscure points.

- Section 5.3.1

   Aggressive NSEC/NSEC3 negative caching [draft-fujiwara-dnsop-nsec-
   aggressiveuse] may also affect the quality of key tag signaling.

  (nit) nsec-aggressiveuse is now a dnsop wg document.

- Section 5.3.1

   When the response code for a key tag query is NXDOMAIN, DNS resolvers
   that implement aggressive negative caching will send fewer key tag
   queries than resolvers that do not implement it.

  In the context of the interaction with nsec-aggressiveuse, I think
  this should be more generalized than the response to a key tag query
  itself, e.g.:

   When a query results in an NXDOMAIN response with NSEC or NSEC3
   that covers the name of a key tag query, DNS resolvers that
   implement aggressive negative caching will send fewer key tag
   queries than resolvers that do not implement it.

--
JINMEI, Tatuya

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 22 Aug 2016 21:57:12 +0000

> On Aug 19, 2016, at 11:38 AM, 神明達哉 <[email-masked]> wrote:
> 

I support adding this caveat.

>  it just in case it's worth considering.

I generally like bi-directional signaling such as this, so I would not
oppose having the server indicate its support for the feature in a response.

I would like to hear from implementors whether or not they feel this places
a burden on the implementation.  I know they already must do things like
retry queries with/without EDNS and sometimes find a UDP message size that
works.  This adds to those state-keeping requirements.

Do we have to worry about middleboxes that would allow the option code in
queries but block it in responses?

We also would have to figure out whether a recursive should signal its
support of the feature to a stub.

>  leaving any obscure points.

I can be convinced either to keep it or to leave it.  My rationale for 
that sentence is to state that a server should not have some built-in logic
that determines the response to these types of queries.  The response code
should be determined by whether or not they are in the zone file (or as you say
covered by wildcard).

>  (nit) nsec-aggressiveuse is now a dnsop wg document.

Ack.

>   queries than resolvers that do not implement it.

IMO your version adds a little unnecessary complexity to the sentence, while
making the same point.

DW

---

From: 神明達哉 <[email-masked]>
Date: Wed, 24 Aug 2016 11:52:54 -0700

At Mon, 22 Aug 2016 21:57:12 +0000,
"Wessels, Duane" <[email-masked]> wrote:

> >  NXDOMAIN, [...]

Okay, I see the point.  In that case I'd state that point more
specifically rather than through one such case of NXDOMAIN, but I'd
leave it to you.

> IMO your version adds a little unnecessary complexity to the sentence, while

I don't think these two are exactly the same, but I won't insist on
the generalized text.

--
JINMEI, Tatuya

---

From: Shane Kerr <[email-masked]>
Date: Tue, 30 Aug 2016 15:00:29 +0800

Paul,

At 2016-08-10 16:54:39 -0700

> sure we're on the right track before we move ahead. ]]

I'm back from vacation and catching up on old mail. I decided to go
through this draft instead of finishing that. ;)

I have a couple questions about the Key Tag Query. (Apologies if these
have been discussed already - I do remember some mention of the first
question in a meeting so maybe it has been discussed and discarded.)

First, can we please just use the decimal version of the Key Tag
values? As an operator it sure is easier to be able to cut & paste from
a log instead of having to use "bc" or Python to convert from the hex
to the value that is actually in all of my configuration files
everywhere.

Second, the easiest way for a querier to use this might be to set up a
cron job that grabs the anchor information out of a configuration file
and sends it via "dig". That doesn't require any support from any
software beyond what I have today, but it doesn't match the idea of
sending it at the same time as a DNSKEY query.

Finally, the security concerns section got me to thinking about ways to
send the trust anchor information in an encrypted way. I don't see an
easy way to do this in the DNS itself, but we could use HTTPS for this.
A zone could add a RR something like:

_dns-trust-anchor-reporting._tcp.$ZONE. $TTL IN SRV 0 1 443 an.example

Then a resolver could use a RESTful query like:

https://an.example/$ZONE/$SRVID/keytag1,keytag2,keytag3

If we really wanted to keep it in DNS do something similar but submit a
DNS over TLS query instead. Maybe:

_dns_trust_anchor_reporting._tcp.$ZONE. $TTL IN SRV 0 1 853 an.example

Then the resolver could use the Key Tag query. This also has a slight
advantage of only reporting information to trust anchor operators who
plan on doing something with the data. It does require DNS over TLS
support though....

Cheers,

--
Shane

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 30 Aug 2016 14:31:35 +0000

> On Aug 30, 2016, at 12:00 AM, Shane Kerr <[email-masked]> wrote:
> 
> Paul,
> 

I have a weak preference for the hex format because IMO it adds some
structure to the message that helps differentiate real signal from noise.

For example I think it is useful to know that "_ta-0033" is a well-formatted
key tag query, but "_ta-33" is not.

I'm not sure about the bc/python argument because I would expect this to
be generally built in to the name server software, and I don't feel that
adding an awk/bc/python one-liner to a shell script to be all the burdensome.

> sending it at the same time as a DNSKEY query.

I suggested tying it to the DNSKEY query for a couple of reasons: (1) thats
how it works when conveyed by EDNS; (2) it provides a consistent interval
across all implementations and gives the zone operator some control over
how often to receive key tag data.

> plan on doing something with the data. It does require DNS over TLS

This seems like too much complexity to me.

DW