Hi!
I'm testing the new exim 4.85 DANE support and it took only some days to
get in trouble...
One of our users tried to send mail to the domain education.lu.
Their domain and MX hosts are DNSSEC enabled and have TLSA RRs.
The DANE validator
https://dane.sys4.de/smtp/education.lu
says: "Unusable TLSA Records". Most likely because it is type 1 not allowed
for DANE-SMTP?
I've set hosts_try_dane = * in my SMTP transport.
Exim refuses to talk to those hosts at all with "failure while setting up
TLS session". Is this expected behavior in terms of DANE-SMTP? What's
postfix doing in this case?
Greetings, Wolfgang
--
Wolfgang Breyha <wbreyha(a)gmx.net> | http://www.blafasel.at/
Vienna University Computer Center | Austria
Hello,
while playing with DANE OPENPGPKEYS i wrote a tool i called pgpfinger.
Its functionality may overlap with hash-slinger but i uploaded it
in the hope it may be of use.
It reads keys from sources: file, gpg, keyserver, dns
And outputs in formats: armored, binary, generic, rfc
Code and packages:
https://github.com/benningm/pgpfinger
Markus
--
Markus Benning, https://markusbenning.de/
Now that the FREAK attack is widely disclosed, those of you who
run SMTP servers that peer with clients that authenticate your
server (be it via the traditional PKI or via DANE), might want to
tighten-up your server cipher-suite settings just in-case:
smtpd_tls_exclude_ciphers = EXPORT, LOW
If nobody has yet elicited and factored any 512-bit RSA public keys
from your server then your unpatched clients will be safe from the
attack. (Not clear how you'd know this).
If your server might have already signed one or more export RSA
keys then its clients are potentially exposed to the attack for
the lifetime of the server's long-term RSA keys.
So, *after disabling* export grade algorithms, it may be prudent
as appropriate to deploy new certificates. If you've published
DANE TLSA records, follow the key rotation process described in:
https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-8.1
Make sure to generate a new private/public key pair, rather than
just re-use the existing key for a new certificate. Make sure to
augment the TLSA record in DNS before deploying the new certificate,
wait 2 TTLs or so, then deploy the new certificate and drop the
obsolete instance of the TLSA record after.
Note that while Postfix clients that do mandatory TLS (authenticated
or not) do not enable EXPORT ciphers, the reason the FREAK bug is
important is that such clients accept ephemeral RSA key transport
with a 512-bit key anyway, while ostensibly negotiating a cipher-suite
that does regular RSA key transport. This is a failure to exclude
state transitions that should be disallowed in the SSL/TLS protocol
state-machine.
--
Viktor.
Hi All,
I'm trying to get to speed on the DANE implementation in Postfix, it appears to support only DANE certificate usage 2 (Trust anchor assertion) and 3 (Domain-issued certificate). Is there a particular reason why the public CA-signed certificate types wouldn't be supported as these are more likely (as of today, at least) to be installed on business and commercial platforms?
Extract from http://www.postfix.org/TLS_README.html#client_tls_dane:
"The Postfix SMTP client supports only certificate usages "2" and "3" (with "1" treated as though it were "3"). See tls_dane_trust_anchor_digest_enable for usage "2" usability considerations. Support for certificate usage "1" is an experiment, it may be withdrawn in the future. Server operators SHOULD NOT publish TLSA records with usage "1"."
Sincerely,
Kevin San Diego
