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

["Wessels, Duane" <[e-mail]>]

> On Aug 30, 2016, at 12:00 AM, Shane Kerr <[e-mail]> wrote:
> 
> Paul,
> 
> At 2016-08-10 16:54:39 -0700
> "Paul Hoffman" <[e-mail]> wrote:
> 
>> [[ 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. ]]
> 
> 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.

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.

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


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.


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


This seems like too much complexity to me.

DW