4.8.2014: To DANE or not to DANE?

Last week, the German press annonuced the 30th birthday of the Internet mail SMTP [1]. This is based on an SMTP mail which has reached Michael Rotert at IRAUKA/University of Karlsruhe on August, 3rd 1984. Of course this was not the start of electronic mail which happend before, in particular using mailboxes and UUCP, but certainly it was the start of the plague hitting the innocent Internet users years later by means of viruses, worms, and spam.

Not only that a participated in the development of the Karlsruhe University in terms of fibre optic networks, FDDI routers, and in particular TCP/IP (and SMTP) on the University computing center's mainframes, but later I began to actively support Dan Bernstein's qmail [2], [3], [4].

SMTP mail was constructed to be an open host-to-host relaying communication protocol. It was never intended to work as user-to-user protocol, thus it lacks all aspects of authentication and encryption. It shares those missing features with it's OSI companion X.400, which was more carefully designed, but failed due to the missing DNS lookup capability which needed to be emulated by means of transport paths (in qmail terms, we call it a 'smtproute').

The more-or-less abuse of SMTP resulted (and still results) in workarounds which actually were not only due to the shortages of the SMTP protocol itself, but rather the rape of it's designed use case -- and today blaming the victim for it's rape [5].

While for qmail, I added most of the missing and wanted features in my Spamcontrol patch [6] on the transport level, the current problems are the user clients. For instance, I use serveral email accounts for different purposes (private, university, ...). Though this can be achieved in most User Mail Agents (MUA), no MUA provides something what is called 'multitenant', in German language more precisely 'mandanten fähig'.

This hits for instance PGP deeply. A well designed multitenant MUA whould allow in addition encrypted mailboxes (better maildirs) and would made the usage of PGP keys more easily. Just as a historical remark: The Eudora MUA version 3.x (running under Windows 3.1) was already multitenant; while the current Mail.app from Apple under MacOS X is not.

However, instead of solving the underlying problems by a qualified design, it is more important to be in the press: DANE [7] is coming! DANE is the acronym for DNS-based authentification of Name Entries (here: TLSA record) which allows to store the TLS certificates (or their fingerprints) in the (secured) DNS infrastructure and thus substituting the compromised Public Key Infrastructure PKI [8].

DANE [9] is discussed as the killing feature to provide reliable SMTP email [10]. Sorry, this is simply not the case. In fact, DANE adds a new authentication channel for the SMTP receiving host in order to verify it's X.509 certificate while using TLS for transport encryption. Actually, this is not a problem. The problem exists on the sender side, where SPF, DMARK, and other means fail their purported aim. For instance, Postfix' policy is to rely on Anonymous Diffie-Hellman (ADH). In short, DANE perhaps solves the problem of potentially X.509 certificat forgery.

If you like to kidnap a mail for a domain, you simply abduct the entire domain including the DNS MX settings (Note: the DNS server parent only signes the Key Signing Key (KSK) and not the Zone Signing Key (ZSK)). Unless the SMTP clients posses some hard-wired fingerprints of the cert, you can't prevent this forgery with DANE.

To conclude, the hype about DANE in particular in Germany regarding DE-Mail and other 'reliable' mail system is just a smoke, which will eventually settle. Supporting DANE seriously at the client side requires a DNSSEC (or DNSCurve) enabled Resolver. Certainly for a MUA that is a respectable requirement. If you just deploy in on the SMTP client of a MTA, it's practical use is limited.

 


[1] www.spiegel.de/netzwelt/web/30-jahre-e-mail-in-deutschland-unertraeglich-unverzichtbar-a-983901.html
[2] cr.yp.to/qmail.html
[3] www.qmail.org
[4] www.fehcom.de/qmail.html
[5] www.heise.de/security/artikel/Verwurmt-verphisht-verspamt-E-Mail-ist-kaputt-1884608.html
[6] www.fehcom.de/spamcontrol.html
[7] www.heise.de/thema/DANE
[8] www.fehcom.net/diary/2012/20120221.html
[9] tools.ietf.org/html/rfc6698
[10] www.heise.de/netze/meldung/DANE-disruptiv-Authentifizierte-OpenPGP-Schluessel-im-DNS-2268917.html