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

[Edward Lewis <[e-mail]>]

On 12/10/15, 13:13, "DNSOP on behalf of Bob Harold" <[e-mail]
on behalf of [e-mail]> wrote:

> that information might be useful to the receiver.

This raises a good point to me.  As someone who will be in the position of
making use of such data (if available), what will I be doing with it, what
granularity is needed?

The receiver of this (the trust anchor operator) is not going to be able to
really act on the information in the sense of fixing "broken" applications.
I mean, if an IP address tells me they don't have my latest trust anchor,
I'm not about to get into a conversation (packet exchange) with them to get
them up to date.

I'm never going to be able to see this as 100% adoption either.  Because
once I put a candidate trust anchor up and being to count the 30 days, there
will always be someone "starting life" with RFC 5011.  The first time a 5011
adherent sees the key might be the 29th day I have it out there.  (Whether
or not such a case is "valid" within 5011's model is another matter
entirely.  Perhaps a validator starting life will have to consult some other
way to get to an initial state of security and that other way may already
declare the candidate to be full-fleldged.  Well, then they'll already list
the key tag.  Hmmm.)

I don't know if there's need to aggregate.  EDNS0 is hop-by-hop and I can't
see that trying to fight its nature will give us a benefit that overcomes
the cost of "tunneling" information through the hops.  If a validating IP
address has to go though a forwarder (in a captive network), what trust
anchors it has isn't really useful to the receiver of the option.

My sense is that when I look at the responses, I'll get a sense of how many
IP addresses hitting my servers have the candidate trust anchor and I can
make a decision to roll.  If I just know about the IP addresses that hit me,
I think that's probably sufficient.  (Am I wrong?)