Subject: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag

From: Tim Wicinski <[email-masked]>
Date: Sat, 28 Nov 2015 07:45:15 -0500

This starts a Call for Adoption for draft-wessels-edns-key-tag

The draft is available here:
https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/

There was unanimous support this during the meeting in Yokohama, so this 
is more of a formality, unless we hear strong negative reaction.

However, please indicate if you are willing to contribute text, review, etc.

Since there was unanimous support for this draft, I am going with a one 
week Call for Adoption. Please feel free to protest if anyone feels this 
is out of line.

This call for adoption ends 7 December 2015.

Thanks,
tim wicinski
DNSOP co-chair

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Nov 2015 13:55:26 +1100

Some feedback with respect to installed trust anchors is needed.

Whether this is the correct solution I'm not sure.  It requires
updating all resolvers in the resolution path to both cache and
relay tags.  The same can be achieved by encoding the tags into
qnames/qtypes without needing the entire ecosystem to be upgraded
which this proposal requires.

e.g.
	_ta_<base32-tag-sequence>.<trustanchor>/NULL

Mark

In message <[email-masked]>, Tim Wicinski writes:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 30 Nov 2015 17:29:53 +0000

Hi Mark,

> On Nov 29, 2015, at 6:55 PM, Mark Andrews <[email-masked]> wrote:
> 
> 
> 
> relay tags.

I'm not sure where you got the idea that a resolver would cache key tags.
The document I've drafted does not propose that.  It does propose that
a recursive would forward key tag values for cache misses.

>  The same can be achieved by encoding the tags into
> qnames/qtypes

Yes, perhaps.  But then we start to run into all the problems of special
use and non-service names, don't we?

As I've said a number of times before, the edns-key-tag proposal is modelled
after RFC 6975, which does the same thing for algorithms.  If it works for
algorithms why wouldn't it work for key tags?

> without needing the entire ecosystem to be upgraded

I disagree with this characterization that "the entire ecosystem" needs
to be upgraded.  Yes a non-key-tag-aware recursive won't know to forward
the option, but this is true for all EDNS options.

DW

---

From: Evan Hunt <[email-masked]>
Date: Mon, 30 Nov 2015 18:12:44 +0000

> algorithms why wouldn't it work for key tags?

Does it work?  Has anyone deployed 6975?  We have an experimental
implementation of it in a development branch for BIND, but we decided not
to release it because the benefits didn't seem commensurate with the extra
complexity and packet size.  I haven't checked to see whether any other
implementations are using it.

We've certainly encountered operational difficulties when sending unknown
EDNS opcodes to broken servers.  Mark has been pushing hard on this issue,
and things are getting better, but it's still a problem.

> the option, but this is true for all EDNS options.

But it isn't true for query names.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Matthijs Mekking <[email-masked]>
Date: Tue, 1 Dec 2015 08:49:40 +0100

All,

I think this is a nice approach for gaining confidence in a rollover of
a key that acts as a trust anchor. It can even be used to detect
validators that have missed the rollover.

I would however be cautious with using the information as an event
trigger. The draft says

   The goal of these
   options is to signal new trust anchor uptake in client code to allow
   zone administrators to know when it is possible to complete a key
   rollover in a DNSSEC-signed zone.

Since the zone administrator can impossibly know whether all validators
have signalled its trust anchor, you cannot use this information to
speed up a key rollover.

Also, the zone administrator already knows when to complete the key
rollover by calculating the appropriate interval times (ttl,
propagation, etc). This signalling does not add anything to that knowledge.

Then some words about the uniqueness of key tags. The draft already
mentions it briefly, but just within the same zone. Since the queries
will visit various name servers, authoritative for different zones, how
do you deal with such key tag clashes. For example, a validator has the
root key set as a trust anchor, and the root and myzone.nl both have
DNSSEC keys with tag 12345. Does the zone administrator of myzone.nl now
also believe that its key is installed as a trust anchor?

Also, like the draft also mentioned, these queries can be created by
anyone and there is no way of authenticating the validator, so anyone
can signal key tags to give a zone administrator a false sense of
confidence. How could an administrator act on that such that valid
signalling stays useful?

To summarize, I am arguing that perhaps more bits than just the keytag
must be signalled, and that more words should be spend on how to deal
with the malicious key (tag) signalling.

Best regards,
  Matthijs