A couple of reactions to this message: On 11/27/17, 10:10, "DNSOP on behalf of Richard Barnes" <dnsop-boun...@ietf.org on behalf of r...@ipv.sx> wrote:
> [one] should know better than to claim that a mechanism that requires > resolver updates will have "immediate benefit" :) I have been impressed by the impact of "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)". Although the document was published in April, it seems that it has worked its way into operating servers quite quickly. I see this as a testament to operators being able to pull off tech-refreshes more quickly as time progresses. That is one aspect of this I am walking away with. But "benefit."? One can debate the benefit of the quickly adopted mechanism. There's a lot of uncertainty in what is being seen, that is what I mean. Not meaning to demean the new mechanism, it does raise concerns about new proposals - which may also come with uncertainty. I recall a conversation from early in 2015, when I lamented the lack of feedback related to Automated Updates (RFC 5011's mechanism). I was told that if we had something, given a lack of a baseline, we would get confused with the results. Later, the "Signaling Trust Anchor Knowledge..." effort (RFC 8145) began and, well, that prophecy has been fulfilled. That's not a failure, just a learning curve. I'd not label it a failure as it hasn't lessened where we are, it has helped lead more investigation even if it hasn't given us something we fully understand yet. >wrong architecture for the long run. I'm unsure of that. I commented earlier that having the query/response mechanism be something the operator of the trust anchor store (connected to a DNSSEC validator that is part of a DNS cache, etc.) can use is a good first step. In the constrained use case of "me owning the test target" (by owning, I mean credentials to access the configuration files of the target) there's a lot we can get from a query/response mechanism. With that, whatever can be generalized for a replying party to glean and then report via a higher-layer test would be good. A (as opposed to "the") test harness (the higher-layer) could then be designed a few different ways. Describing the one the draft has in mind is a good idea, what I mean is that there could be other ways. I can understand reluctance to accept a particular way to perform the test, but to throw out the under layer with that bathwater isn't the best way to go. I had originally set out to agree with the "wrong architecture" for this reason though - I'd wish that there was a better description of managing secure entry points and trust anchors along the lines of a three-way handshake protocol. This begins with - how does a trust anchor manager know that it should be managing (pinning) keys for a domain, etc.? I'm not sure we can get there though.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
