On 9.11.2017 15:39, Edward Lewis wrote: > To set up the problem to solve. Asking for points that are missed. > > (Purposefully omitting the trailing dot, not talking about 'root' because > that could get confusing.) > > Trust anchor for "one/17" (i.e., key_id=17) > > Trust anchor for "two.one/145" > > Received data for "three.two.one" signed by "two.one/9342" > > What would cause "two.one/9342" to be signed by "one/17" and not by > "two.one/145"? (I think this captures the question of interest.) > > 1. "two.one/145" is in the MISSING state from STD 69. > 2. "two.one/145" was revoked but the validator didn't remove it. > 3. "two.one/145" is stale, as the validator is not using STD 69. > 4. "two.one" was re-delegated, the previous holder still uses "two.one/145" > 5. (open for more scenarios of "why") > > What should the validator do with the response? > > For cases 1,2,3, the chain ought to be accepted. > > For case 4, although the appropriate DNS response (according to the DNS > protocol) was received, the application calling it might not want to take > action based on the response (action such as open a connection and/or flow > data). > > Is there a way, within the DNS, to differentiate amongst the reasons why the > response is signed up to "one" and not "two.one"? > > Is there a way the application can tell? > > With DANE as "an application" in mind: When it comes to DANE, what bothers > me is this, in "DNS-Based Authentication for TLS", the section "The > Certificate Usage Field" (that is RFC 6698, section 2.1.1), for value "3 -- > Certificate usage 3". For that value, this is stated: "PKIX validation is > not tested for certificate usage 3". My reading of this is that the > "problem" with PKIX certificate authorities has just been shifted over to DNS > hosting services (in this case for "one"), concerns about the DNS hoster are > on par with concerns regarding the certificate authorities. (In essence, > either could re-delegate a name.) (Yes, this is a tangential off-shoot, > anticipating questions about how DANE plays with this.) In essence, usage 3 > removes the benefit of pinning, which the application could use to detect a > re-delegation.
Nice write-up Edward! You have nicely summarized why Mark and me agree that validator should use longest suffix match when selecting TA to validate data. Things might get even more complicated when negative trust anchors are configured, bleh. Let me repeat that I very much prefer longest suffix match because it is predictable, easy to understand, and thus more secure than "use any". (And again, this is relevant only to people who bothered to configure TA for domain different than root, i.e. largely irrelevant for vast majority of users.) -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
