On Sat, Oct 06, 2012 at 11:16:13AM +0200, Nikos Mavrogiannopoulos wrote: > I think that DANE is _too_ complex for its purpose. > > 1. DANE does not imply DNSSEC, and verified using DANE may mean nothing. > Why? Is there any reason not to require DNSSEC?
DANE (at least as documented by the RFC 6698) _does_ require DNSSEC. RFC 6698, Section 4.1. > 2. Too many certificate usage fields to indicate the _same_ thing. Nope, no two certificate usages are the same. > Certificate usage 0 is exactly the same as 2, and usage 1 is the same as > 3. The difference is that if my certificate is signed by a CA I use 1, > but if the CA signature expires but I don't renew I have to notify the > DNS administrator to change it to 3. That's quite interesting. What is > that for? Nope, those are not the same. E.g. usage 1 _requires_ performing PKIX path validation, whereas usage 3 does _not_ require path validation. (In fact, usage 3 is by far the simplest one to implement; does the EE cert slot match one of these, yes/no). You can use 2/3 even if your certificate is signed by public CA. You just likely won't get any indications of security above DV level. 0/1 are only really useful if you have a OV or EV certificate. > The same if I have a self-signed certificate that one can verify using > DANE. If I decide to buy a signature from a CA to increase security, I > actually create confusion for the users of DANE. Users of DANE would see > the certificate usage 3 in my public key, and what should they think? If the usage 3 entry matches, ignore your CA certificate and proceed with the connection. If those don't match, consider other entries as usual (if none matches, reject the connection). Of course, if your CA certificate is EV (or OV), you only get DV security. > 3. Too many options for the selector field. > Note that having more options is not better, it is worse because of > incompatibilities. People will ignore DANE verification due to the many > false positives. Why allow _both_ full X.509 and SubjectPublicKeyInfo > fields? What is the advantage? The answer is none. This goes to dark territories of PKIX, but sometimes certificates are internally replaced without changing then SPKI. As to being able to bind to full certificate, there may be some advantage under rather contrived scenarios. But it is simpler to implement, since you won't need to even rip the SPKI out of the certificate... > You could also have > allowed raw RSA keys, raw RSA keys that have e and m reversed and so on. > But more options do not add additional security. There selectors truly do not add anything and are thus not there. In contrast, SPKI is always a proper substring of the certificate, and there is no room for interpretation how it should be put together given certificate. If there ever will be a raw RSA key type (seems unlikely, as it would require TLS WG to standardize a raw RSA key type), it will be its own usage, not its own selector. -Ilari _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
