Hi, On 15-12-17 02:51, Paul Hoffman wrote: > Please see > <https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/1>. This is a > small set of changes that make the draft not treat the root zone as > special. It allows the labels to be used for any zone, not just the root.
I agree that a mechanism that works for all trust anchors (like RFC8145 does) is preferable. I am, however, not sure that this suggestion works. If I understand this proposal the idea is to use the keytag to find the correct TA. This might work for most cases but it is possible to have a non-root TA with the same keytag as the root. Or someone can, for some weird reason, configure the root key as one of the entries for a local TA. For this mechanism to work, the validator need to know the TA's zone. This can be done by always using the root or by signaling the TA name, for example in the query. The latter can be as simple as using the TA for the qname without the special label. So: - _is-ta-<tag-index>.example.com. -> applies for example.com TA - _is-ta-<tag-index>. -> applies for root TA In this case only the root zone manager can control the test addresses for the root TA, which some might see as a downside. Also, Geoff's remark about information disclosure still stands. If the consensus is that this mechanism only has to work for the root TA then this should be made more clear in the document. The document now talks a lot about "a key in a trust store" instead of the root key. It only becomes clear somewhere halfway the 2nd section that it only works for the root TA. Some other remarks regarding the draft-ietf-dnsop-kskroll-sentinel document: The three times SERVFAIL case in section 4 can be distinguished from a SERVFAIL for another reason by using a 4th query for a signed domain without special labels. If only that one succeeds you know for sure that a key roll will give issues, unlike in the indeterminate (Vleg) state. Is there a reason why this mechanism should only be applied for A and AAAA queries? "if the left-most label of the original query name matches the template "_is-ta-<tag-index>."" The trailing dot should not be part of the label. If this mechanism should only work for the root TA, what should a validator do when the queried for name is covered by a non-root TA? Not applying this mechanism, or applying it for the unused root TA? Some editorial nits: - trust anchor vs Trust Anchor, both used in document - section 2: aplied -> applied - section 3, Vleg: "RRSET" -> "RRset" - section 3, Vleg: "an A record" -> "an A or AAAA RRset" Regards, -- Ralph Dolmans _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
