On Tue, Jun 09, 2015 at 06:23:28PM +0000, Dan York wrote:
> Testing DANE For Sending Secure Email at the Go6lab
>
> http://www.internetsociety.org/deploy360/blog/2015/05/testing-dane-for-sending-secure-email-at-the-go6lab/
Good to see folks getting their feet wet. They posted some settings
they used:
smtpd_use_tls = yes
smtpd_tls_security_level = may
smtpd_tls_key_file = /etc/postfix/ssl/server.pem
smtpd_tls_cert_file = /etc/postfix/ssl/server.pem
smtpd_tls_auth_only = no
smtpd_tls_loglevel = 1
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
smtp_tls_security_level = dane
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes
smtp_tls_loglevel = 1
tls_random_exchange_name = /var/run/prng_exch
tls_random_source = dev:/dev/urandom
tls_smtp_use_tls = yes
I suggest dropping a few of these:
# Obsolete
smtpd_use_tls = yes
smtp_use_tls = yes
# Unwise, best to restrict SASL to TLS clients
smtpd_tls_auth_only = no
# This is already the default value
smtpd_tls_session_cache_timeout = 3600s
# Unnecessary when TLS is enabled for all
smtp_tls_note_starttls_offer = yes
# No such parameter exists.
tls_smtp_use_tls = yes
They neglected to mention:
smtp_dns_support_level = dnssec
http://www.postfix.org/postconf.5.html#smtp_dns_support_level
As mentioned above, Postfix is not a validating stub
resolver; it relies on the system's configured DNSSEC-validating
recursive nameserver to perform all DNSSEC validation.
Since this nameserver's DNSSEC-validated responses will be
fully trusted, it is strongly recommended that the MTA host
have a local DNSSEC-validating recursive caching nameserver
listening on a loopback address, and be configured to use
only this nameserver for all lookups. Otherwise, Postfix
may remain subject to man-in-the-middle attacks that forge
responses from the recursive nameserver
And I think everyone needs to mention the need to handle TLSA record
updates on future key/cert rotation. All well and good to get DANE
working initially, but not so good if it is forgotten, and breaks
later.
I'm sorry they found the documentation of "dane-only" unclear. It
behaves as promised, DANE authentication is required. This is for
explicit policy with specific "partner" domains.
> In this second post he recounts how he created some scripts to analyze
> the top 1 million Alexa domain names and to determine how many of them
> are publishing TLSA records. And his scripts went out and initiated
> connections to over 473,000 mail servers to find out how many were using
> TLS in general and how many were using TLSA specifically. All of his
> statistics and other information can be found in that post.
As for Alexa, it is a compilation of web sites, not SMTP domains,
so it is not a comprehensive source for the latter. The list of
domains they report is not quite right, for example mail.netbsd.org
is not DNSSEC validated.
Out of ~1400 domains I found with working MX host TLSA records,
only 39 were listed by Alexa (at some point in the last year). Of
the 19 that are also in Google's email transparency report, only
7 are listed by Alexa.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
