--On Sunday, March 01, 2015 20:27 +0000 Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: >... >> > Whether your MTA uses STARTTLS or not is another matter >> > but we can prevent downgrade attacks from succeeding. > > If the MTA implements opportunistic DANE TLS, and usable TLSA > records *are* published, then it MUST use STARTTLS and > authenticate the peer via said TLSA records. > > http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-14#s > ection-2.2 Victor, Please don't get too excited about statements like that, whether they are written into I-Ds or not. There are two separate clusters of problems with it: (1) Email, including SMTP, is based on a very old set of protocols. For reasons that are historical but still relevant today, there is extensive deployment of the protocols in embedded environments, many of them old enough that there has been no option to upgrade them even to ESMTP and MIME, which are now themselves over 20 years old. Precisely because it works well and is all but ubiquitous, email provides a communications mechanism that has been plagued in recent years by spam, phishing, and email-spread malware. Those problems have brought about operational changes and the "operational necessity" escape clause in RFC 5321. For other reasons, the mail system, almost unique among IETF application protocols, is designed around a hop by hop model, not an end to end one. While that design was originally important because of intermittently-connected destinations and gateways to systems running other mail protocols, it is now commercially vital for third-party provisioning of enterprise mail systems (whether motivated by antispam or other operational concerns). As in the earlier days, hop by hop models are difficult from a security standpoint because the initiating client cannot be guaranteed to have the ability to negotiate or handshake with the final destination server. It may be able to negotiate with an intermediate that acts on the destination's behalf instead, but such negotiations involve all of the difficulties with a trusted third party whose identity and trustworthiness are hard to verify. (2) The very essence of all, or almost all, mail-based phishing attacks involves having someone accept a domain name, email address, or URI as legitimate when it is actually not the user-intended one. Neither DNSSEC nor DANE prevent or detect those attacks. They may actually be harmful if they give the user a false sense of security. The main protections against such attacks lie in user awareness, tools that identify or highlight suspicious domain names or domains or addresses that are known to be malicious, and a high degree of integrity by registrars. The latter has, at least IMO, proven to be a failure. In particular, when malicious parties can easily register domains with misleading names, all DNSSEC does is to verify that the DNS records were not altered in transit and DANE is as happy to provide key material associated with a malicious domain as a desirable one. john