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

[Bob Harold <[e-mail]>]

On Wed, Dec 9, 2015 at 3:27 PM, <[e-mail]> 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 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/



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.