XS4ALL enables DANE validation for outgoing mail
XS4ALL has recently enabled DANE validation for all outgoing mail. That means that, before delivering each message, the company's outgoing mail server (smtp.xs4all.nl) will check whether the recipient's domain has a TLSA record for mail. If it does, the hash in the TLSA record will be used to validate the TLS server certificate on the receiving mail server (MX gateway). As well as cryptographically pinning the server certificate using the DNSSEC infrastructure, the procedure will prevent a downgrade attack on the SMTP STARTTLS capability.
Until now, XS4ALL's mail server has been in soft-fail mode: the Cloudmark Gateway has been configured so that, in the event of a DANE validation error, the e-mail message concerned is re-presented a few seconds later and the validation procedure dispensed with.
Within a few weeks, we hope to be able to change the setting to a hard fail, says system manager Jan-Pieter Cornet. We've collected about two months' worth of log files. The errors recorded in the logs are mainly DNSSEC errors (e.g. rare NSEC records, the unauthorised use of CNAMES in MX records, and problems with wildcard records) and issues with DANE itself (records that don't match the certificate). The problems appear to be associated with a handful of hosters, so we'll have to talk to them.
DANE for client domains
Cornet expects DANE for mail to really take off in the period ahead. DANE for web will probably take longer to get established, because of resistance from the CAs, who see it as a threat to their revenue streams.
Fortunately, DANE is on the Forum for Standardisation's 'use-or-explain' list (and DANE for outgoing mail will probably be added soon). Clients often mention the 'use-or-explain' list when they ask us about DANE. If we have enough interest to make a business case for enabling DANE for client domains, we may implement DANE in our client interface in the future.