Viktor Dukhovni wrote: > On Sat, Dec 28, 2013 at 05:56:41PM +0100, Michael Str?der wrote: > >>> http://vdukhovni.github.io/ietf/draft-ietf-dane-smtp-with-dane-05.html#rfc.section.1.2 >>> >>> This is why I am working to implement and standardize SMTP with DANE TLS. >> >> DANE itself does not help. It just shifts the trust anchor problem. >> >> DNSSEC secures the MX lookups. > > For the record: > > While indeed SMTP with DANE TLS relies on DNSSEC to secure the > MX lookup, it also critically relies on DANE for two additional > pieces of information: > > - Downgrade resistant STARTTLS support signalling. Without > this MITM attackers simply suppress STARTTLS and the sender > proceeds in cleartext.
This entirely depends on the fallback configuration of the sender. Proceeding with clear-text communication also happens with DANE/TLSA if the sender is configured to send the message in any case. > - TLS support signalling is combined with signalling that the > peer can be authenticated and all the key material needed to > perform authentication. Nothing really new. The key material has to be authenticated anyway by validating against some trust anchor. > Sending MTAs run unattended with no > user to "click OK". They must not routinely fail due to > Goedel's theorem for CA bundles (any set of trusted CAs is > either insecure or incomplete). > > - Since it is already agreed that DNSSEC must be trusted to > protect the MX records, eliminating the CA bundle from the > picture reduces risk AND improves reliability to the point > where peer authentication with SMTP becomes usable. It is > NOT usable with CA bundles. Blaming CA bundles is somewhat right. But just using another data format/transport is not a solution to the trust problem. If DANE/TLSA gets ever widely adopted you will see the very same discussions about how to reliably establish trust. Time will tell. And in the light of recent news I'd rather vote against having a U.S. centric DNS trusted root key. > but I am not obligated to provide a comprehensive > justification in response to every trollish one liner, the above > will have to do. Uuuhuuh. Just writing lengthy blog articles is not helpful either to analyse trust problems not to speak of inventing a real solution. Ciao, Michael.
smime.p7s
Description: S/MIME Cryptographic Signature
