On 12/10/15, 13:13, "DNSOP on behalf of Bob Harold" <dnsop-boun...@ietf.org on behalf of rharo...@umich.edu> 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?)
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
