German infosec bureaucrats want mail providers to encrypt

It's not so often that the dense and often dull documents that are our Internet standards attract the endorsement of governments, but that's what has happened with RFC 7672. Part of 'net boffins' ongoing effort to rewrite standards for better privacy, the standards-track RFC (SMTP Security via Opportunistic DNS-Based …

[Vic]

DANE TLSA records, the RFC states, give (for example) a mail server a way to say "I support TLS", and publish how SMTP clients can authenticate servers.

You don't need DANE for that - MTAs already declare their TLS capabilities.

[vic@perridge ~]$ dig +short mx theregister.co.uk

1 aspmx.l.google.com.

5 alt1.aspmx.l.google.com.

5 alt2.aspmx.l.google.com.

10 aspmx2.googlemail.com.

10 aspmx3.googlemail.com.

10 aspmx4.googlemail.com.

10 aspmx5.googlemail.com.

[vic@perridge ~]$ telnet aspmx.l.google.com. 25

Trying 64.233.167.26...

Connected to aspmx.l.google.com..

Escape character is '^]'.

220 mx.google.com ESMTP fi7si37083059wic.91 - gsmtp

ehlo example.com

250-mx.google.com at your service, [217.169.14.82]

250-SIZE 35882577

250-8BITMIME

250-STARTTLS

250-ENHANCEDSTATUSCODES

250-PIPELINING

250-CHUNKING

250 SMTPUTF8

As you can see, ElReg's MX supports the STARTTLS command, and all that without touching DANE...

Vic.

[Sebby]

Yes, but that by itself is not ensure that the transaction is encrypted, and using the correct keying material. Without TLSA records * there is no way for the client ** to know for certain whether encryption is supported or that the key is correct; if an attacker in the middle strips away the advertisement of STARTTLS then offering it is useless because the client will helpfully fall back to plain text, or if the certificate is replaced by a compromised one, the client will just use that instead.

This is fantastic news, really. Both Exim and Postfix can do it now IIUC; get your DNSSEC-aware nameservers and your MTAs ready. :)

* TLSA records are secured using DNSSEC. I make no comment concerning the trustworthiness of an ultimately single-source root-anchored chain of trust, except to say that user visibility into that root, or any subordinate identified by domain suffix, is likely to be superior to the current CA regime.

** The client is an SMTP server delivering mail onward, for those unaware; this is not the same as a user agent authenticating to a mail server, which requires a private arrangement to ensure is safe.

[Anonymous Coward]

Am I the only one

Getting sick and tired of all the hacked on DNS extensions to make SMTP function better for spam control, authentication, encryption, and so forth?

Can't someone PLEASE invent a 21st century mail protocol that isn't burdened by backwards compatibility to do all this stuff? We can support it in parallel with SMTP for a number of years, but at least we won't have to keep layering ugly hacks onto DNS to support SMTP's overly trusting 35+ year old design.

[John Savard]

Will It Do Any Good?

I was just reading another article which noted that encrypted E-mail, unlike some other encrypted Internet services, is still using 512-bit keys which are now weak enough to be broken on cloud services like the one from Amazon. So asking for encryption isn't enough; it will be necessary to ask for good encryption!