On Apr 16, 2013, at 4:56 PM, Viktor Dukhovni <[email protected]> wrote:
> On Tue, Apr 16, 2013 at 04:42:24PM -0700, Paul Hoffman wrote: > >>> The TA whose *digest* is in TLSA is "Some issuer 3 (of 2)" whose >>> certificate is not sent in the server chain. How is the client >>> supposed to verify the chain? >> >> As Jim points out, the client might already have it pre-loaded. >> If the client doesn't have it pre-loaded, the TLS handshake fails. >> >> Getting the key or certificate from the TLS server would help, >> but it is not required for the scenario to work. > > Yes, some clients *might* have the certificate in hand, and *might* > be able to use it augment to augment the chain, and thus *might* > be able to use the TLSA association, How is this different than all of the "mights" in TLS? > but this is not a basis for > an interoperable protocol. Sure it is. There are plenty of things operators can do wrong, of course. What you are proposing is (perfectly reasonable) operator guidance, not a protocol requirement. > A client that uses DANE to authenticate servers per their TLSA RRs > or else fail must have some assurance that conformant servers can > be verified. This makes no sense at all. The whole point of path validation is that they don't need assurance, they can verify each step of the chain. > I am writing a client that needs to know whether certificate usage > "2" TLSA RRs are "usable". Failure to authenticate peer SMTP > servers and delayed email will not do anyone much good. The idea > is to promote DANE and DNSSEC adoption not give both a bad name. Great! Don't give them a bad name then. (Well, no worse of a name than SMTP...) > Can I expect server operators to provide the TA certificate in the > TLS handshake server chain? If so on what basis? Their incisive > logical reasoning ability? Operational guidance is always welcome. We have some of that in the TLSA spec, but more would be useful. > If I can't then usage 2 digests are "unusable". Shipping code that > makes mail delivery fail to RFC conformant peers is not particularly > attractive. Serious question: does your code somehow make sure that every SMTP client and every SMTP server can always agree on ciphers? (This is, of course, impossible.) If not, how does that differ from a PKIX administrator doing something stupid like only handing out the hash of a public key instead of the public key? These two situations can be prevented in the same way and have the same dire consequences if the operators mess up. --Paul Hoffman _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
