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. > > BTW: you probably misunderstood Jim's shorthand for type 2: there are no PKI > checks because it is a trust anchor. > > > Does the group believe that in practice most TLS applications do > > CRL and/or OCSP checks and it is operationally easier to publish > > a timely revocation via a public CA than to maintain sensibly short > > RRSIG time limits and update one's own DNS when a key is lost? > > > > If this is not the case, then why doubt the DANE binding? > > I'm not sure anyone suggested trusting the DANE binding. > > > [ One data point if you like: though Postfix has supported TLS for > > a decade, it doesn't and won't have CRL or OCSP support, but it > > will soon have DANE support. ] > > > >> For type 3 - I would agree that no PKI checks are to be done. That would > >> include the name matching check. > > > > Thanks, I hope this is the consensus view of the working group. > > 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. 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". 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. e.g. https://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html It will also make it much harder to go from DANE usage 3 to DANE usage 2. 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. -Martin _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
