On Sat, Oct 06, 2012 at 11:16:13AM +0200, Nikos Mavrogiannopoulos wrote: > 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. > > 1. DANE does not imply DNSSEC, and verified using DANE may mean nothing.
Incorrect. Re-read section 4.1. If you don't understand the DNSSEC states cited there, you're going to need to read RFC 4033. > 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. They aren't. 0 & 1 validate against your client's trust anchors. 2 & 3 do not. If we didn't have 2 & 3, then self-signed certificates cannot be used with DANE. If we didn't have 0 & 1, then certificate revocation and trust anchor changes would be ignored. (Think DigiNotar.) Different people care about different things. > 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? Ignoring whether an end-user should ever be exposed to this level of detail, they should think that the person configuring the record used a CA for compatibility with non-DANE clients but doesn't put a lot of trust in the CA they got their certificate from. Also, maybe, they serve clients that don't have their CA in their trust store, so they might be hoping that using 3 lets them reach a few more people without trouble (I don't think any CA is in 100% of clients -- I usually see 9x.x% numbers). > 3. Too many options for the selector field. > Note that having more options is not better, it is worse because of > incompatibilities. Incompatiblities? > People will ignore DANE verification due to the many > false positives. Why allow _both_ full X.509 and SubjectPublicKeyInfo > fields? Because: (full X.509) fields other than the SubjectPublicKeyInfo affect X.509 validation, so being able to prevent them from changing may be important to you. (SPKI only) transvalidity is evil, but an unfortunate reality. Sometimes I can't be sure of anything but the key. See Appendix A.1. Hope this helps, -- Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
