I think that name checks MUST be performed when validating certificates marked with usage 1. (And 0 & 2 obviously)
Whatever your feelings on CAs are, DANE includes options to use them, and to assert that a certificate is valid within the CA system. Making name checking optional for Usages 1 means that a certificate *may not be valid* through the CA system but is still accepted. Thus I feel it violates the intention of the RFC with regards to Usage 1: To assert validity through BOTH DNSSEC and the CA system. > Does anyone have a real example in which a validator that ignores > the CA signed name with certificate usage 1 (but not revocation, ...) > faces a new tangible risk they don't face if they perform the name > check? If there are no such examples, no RFC should compell the > TLS client to check the (inside the cert) name bindings from the > issuing CA in cert usage 1. Stated simply: No, not today. (Because if you can change the record you could change it to Usage Mode 3) But I don't think that DANE in isolation is the only thing to consider. I think you should also consider how it can interact with other policy mechanisms. DANE, HSTS, Public Key Pinning, Content Security Policy - these are all mechanisms to assert that a site desires a certain security policy and asking the client to enforce it. Usage Modes 0 & 1 state "In addition to my policy here, you should follow this other (admittedly nebulous) policy." Ignoring name checking in 1 breaks that statement. Consider a situation where a domain asserts, through a new policy mechanism[0], that it ONLY wishes to use Usages 0 or 1 with the intention of requiring a validity assertion through both systems. It's a simple fact: it's harder to hack two unrelated systems than it is to hack one. So if I recieve a DANE Usage mode of 2 or 3 - I ignore it, because that's invalid, someone must have hacked my DNS. Ignoring name checking in 1 breaks that new policy mechanism. > In the long run, good riddance to the existing public CA PKI. Lots of people expressed that opinion, but the rough consensus model showed us that there was support for both supporting the CA model in Usages 0 and 1 and doing without it in Usages 2 & 3. Disabling name checking in Usage 1 feels like trying to give that rough consensus a run-around and invalidate what was decided with regards to Usage Mode 1. -tom [0] As an example: https://domainpolicy.org/ _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
