On 10/06/2012 03:03 PM, Ilari Liusvaara wrote: >> 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.
At least 3 host names in the list of DANE test sites do not use DNSSEC. http://www.internetsociety.org/deploy360/resources/dane-test-sites/ >> 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. Well, my point is that they transfer exactly the same data. 0 transfers an end-entity certificate and so does 2. They differ, as you say, on what the receiving party does on that data. Why bother? How would a server operator ever know what the receiving party will do on the data? Let's say I'm on an company that has it's main web site signed with a CA certificate that is installed on all employees computers. Do I use 0 or 2? All employees perform PKIX path validation so it should be 0. Now you connect to this site, but you don't trust this CA. So it should have been 2, or both? PKIX path validation is a process that runs on the client and the server has no indication whether it will actually occur, or that it will share a common trusted party at all. DANE would help in the cases the peers do not share a common trusted party by providing an indication of the identity of peer. However, the DANE protocol goes to extremes only. Either the server shares nothing with no-one (self-signed), or shares a CA with everyone. Reality is somewhere between those extremes. What the writer of the RFC may have meant, is whether you do a verification against the commercial CA set in a browser. However, this set varies from browser to browser and scenarios like the one above will occur. > 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. OV or EV are pretty much marketing terms, they shouldn't have been considered in a protocol. >> 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. Doing that I would reduce the security of the connection. By ignoring the CA certificate I put the trust on the DNS administrator only. My goal as an implementor of DANE is to disperse the trust to various parties and warn the user of any discrepancy. With the mix or 0,2 and 1,3 I see many cases of false alarms and eventually users disabling the DANE verification. >> 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. Indeed, and this is why only the SubjectPublicKeyInfo should have been defined. Now several DANE tools support only the X.509 format but not the SubjectPublicKeyInfo. I expect other tools from other implementors to only support the SubjectPublicKeyInfo (we had this in other protocols), just to be incompatible with them. Not to mention misconfigured servers that indicate a SubjectPublicKeyInfo, but send an X.509 hash. Those are not things that typically occur in a _new_ protocol like DANE. You see these in a 10 year protocol with a gazillion of options added through the years. DANE has already too many in its first incarnation. > 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... Does it really worth it? Was it like 3 lines of code saved, at the cost of an extra protocol option? Now as a library author, I had to implement _all_ cases actually coding much more than if only one of the SubjectPublicKeyInfo or X.509 had been defined. >> 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. They add the same as X.509 adds to SubjectPublicKeyInfo (or vice-versa). That is nothing indeed. regards, Nikos _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
