On Tue, Mar 05, 2013 at 05:14:32AM +0100, Martin Rex wrote: > Paul Hoffman wrote: > > Viktor Dukhovni <[email protected]> wrote: > > > > > On Mon, Mar 04, 2013 at 08:25:00PM -0500, Jim Schaad wrote: > > > > > >> For types 0, 1 and 2 - the DANE check is in addition to ALL existing PKI > > >> checks. > > > > > > So the client validates two separate cryptographically signed name > > > bindings (DNSSEC and EE cert contents), just to maximize the odds > > > of failure? Why? What is gained by such checks? > > > > The asserting party doesn't have to worry about a rogue CA.
Yes, of course, with 0/2. With 1, the asserting party told the client *exactly* which certificate to expect. That's it game over. With the EE certificate pinned-down, who cares about the name asserted by the CA. What concrete threat does the name check avert? It is not enough to "feel more secure" with the extra check in place, that looks like security theatre, there must actually be a real use-case in which the client avoids an attack by checking the CA asserted name. What is that use-case and attack? The only plausible use-case I see is that the PKIX CA checks facilitate revocation support, if one believes that revocation via public CAs is easier than removing records from DNS in a timely manner. Revocation checks are just as effective without the name check being performed. > > Nothing in the RFC indicates that the relying party would > > do name binding for type 3, I hope. > > I have a very very very bad feeling about this. Scars from the beatings of X.509? My response "doctor it hurts when I do that" is the usual one. > Making a server cert for a server in DNS zone example.org succeed a > name check for DANE usage type "3" might be as simple as creating > such a cert with a "CN=*.example.org". How many domains will have domain names in certs that will be raw UTF-8 rather than encoded as Punicode IDNs? How many will have multiple conflicting CNs? How many client applications won't support "*" wildcards or will vary in whether "*" means arbitrarily deeply nested hosts or just hosts in the immediate domain? > Sending out the message that there are conditions when the name should > be entirely ignored by TLS clients will cause creation of more new problems > (and less of the existing problems getting fixed) in the long run. In the long run, good riddance to the existing public CA PKI. > e.g. https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html bugs due to complexity we have the opportunity to reduce. > It will also make it much harder to go from DANE usage 3 to DANE usage 2. This claim deserves evidence. Self-signed certs will need to be replaced to switch from 3 to 2 whether or not the self-signed cert bears a name. > And it might cause users to ignore names and other cert attributes, > because most users will not understand the difference for name validation > between DANE usage 0,1,2 and DANE usage 3. Users should not be burdened with understanding certificates at all. With DANE, the application simply makes a secure connection, or fails. Users won't be revalidating DNSSEC RRSIGS in their heads, computing SHA256 checksums, ... DANE will make TLS security scale, and asking users to trust certificates signed by "Honest Achmed's Used Cars and Certificates" will fade into distant memory. https://bugzilla.mozilla.org/show_bug.cgi?id=647959 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. [ FWIW, I'm still planning to ignore names with 1/3 in Postfix, as the suggested checks seem to have only negative value (they may fail) without redeeming features (they may avert a real threat). ]. -- Viktor. _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
