Hello, In this mail I list the issues I noticed while implementing DANE. No matter the direct language they are comments in good faith. They may be wrong because of my misunderstanding of the protocol, so feel free to correct me if this is the case.
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? How would a user that uses DANE over DNS and a user that uses it over DNSSEC understand the difference? What is the added value of using DANE over DNS? The RFC claims that there is no harm, but there is no reason either and in addition it introduces issues due to misconfiguration. Bottom line: DANE w/DNS adds no additional security and has the risk of verification false positives due to misconfiguration, so IMO no point for it. (DANE w/DNSSEC also introduces the risk of misconfiguration _but_ it adds additional security if configured properly) It is also a marketing issue. DANE should mean something better than before (i.e. dnssec), not just the same thing as before with a new name. 2. Too many certificate usage fields to indicate the _same_ thing. It is nice to see that there is a document (RFC6394) describing DANE real-world use-cases, but then the main protocol instead of defining a single protocol to cover all use cases, it makes several subprotocols for each use case. There are 4 certificate usage fields but only 2 of them are actually different. 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? So that the user knows that my certificate is expired? He already knows that. 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? That they are under attack, or that 3==0 and that this is a common misconfiguration? 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. 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. My suggestion would be to simplify DANE by having a profile that is simple to implement and understand its purpose. That is: * Restrict DANE only with DNSSEC. If there is no DNSSEC, then there no DANE. * Deprecate usage fields 2 and 3. The serve no real purpose. * Only allow selectors for SubjectPublicKeyInfo. regards, Nikos _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
