On Sun, Jan 13, 2013 at 07:34:24AM +0000, Bry8 Star wrote:
> When can we expect a Postfix release, that will support DANE
> protocol ? so that it(postfix) can verify (using DANE & DNSSEC
> protocols) the signed (and free) SSL/TLS certificates(cert) (or
> fingerprints) which we can pre-add in TLSA, (CERT, HASTLS, etc) DNS
> (DNSSEC) records, and then it(postfix) will use those(cert) for
> secure (smtp) communication, and to verify SMTP servers.
If all goes well 2.11, with snapshots incrementally adding support
for DANE in the works. DANE support is code-complete, but requires
further code review and testing. To that end I would like to see
more mail receiving sites to sign their DNS zones, and publish TLSA
records for their MX hosts.
Thus far, I'm aware of just six MX hosts in four DNSSEC-enabled
domains that have TLSA records for SMTP. Of these:
- 5 publish "IN TLSA 3 1 1 ..." SHA256 public-key digest records,
which is a best practice, that's exactly what most people should
publish.
- 1 publishes "IN TLSA 3 1 2" which is also fine, since the only
difference is that the digest uses SHA512.
All six verify. I'd like to also test:
- "3 0 1" certificate digest RRs.
- "3 1 0" full public key RRs.
- "2 0 0" full certificate trust anchor RRs.
- "2 1 1" public key digest trust anchor RRs.
For "IN TLSA 2 1 1" the trust-anchor certificate must appear in
the server's SSL handshake trust chain. With just the public-key
digest, it is impossible to actually verify the chain.
I don't expect that administrators will publish their trust anchor
in full via DNS, rather they should publish the digest in DNS, and
provide the certificate in the SSL handshake. (In practice they
should shun all certificate usages other than 3).
If you have a DNSSEC-signed zone and operate MX hosts for that
domain that support inbound STARTTLS, please publish TLSA records,
and let me know which domain has said MX hosts.
> Currently (Jan 12, 2013), the last+stable GnuTLS, now supports DANE,
> (and as of right now, OpenSSL (or any openssl modules) yet does not
> support DANE). Can postfix utilize DANE libraries from gnutls for DANE ?
We don't need a new OpenSSL, its verification callback provides
sufficient rope.
The DANE code in the verification callback is a miniscule portion
of the new code. Most the hard work went into the SMTP policy
engine that finds, evaluates and caches TLSA RRs, making them
available to the SSL verification callback. A bunch more effort
goes into making sure that MX record and host to address resolution
tracks the DNSSEC validation status of the results.
Also ~1000 lines of code in the command-line smtptls-finger utility
so one can test before deploying and debug TLS problems if something
goes wrong.
> The DnsSec-Tools.Org site shares PATCH (developed by Sparta) for
> (older) Postfix (and other software) to support DNSSEC, can someone
> expert apply it(patch) on the last+stable postfix ?
> http://www.dnssec-tools.org/howtos/postfix-2.3.x-dnssec-howto.txt
Their patch is largely misguided, no need for explicit DNSSEC
validation in Postfix. You get that for free by deploying a
validating cache (say "unbound") on your machine, and configuring
Postfix to query that cache. Far better to have DNSSEC validation
code in software focused squarely on DNSSEC support.
Once you do have access to Postfix with DANE support, you'll find
that initially it makes no difference at all, since there are as
yet essentially no SMTP servers that publish DANE records.
Since this is a chicken and egg problem, let's hope I'm laying an
egg. :-)
Perhaps, motivated by an MTA that supports DANE, receiving sites
will start to deploy DNSSEC signed zones and publish TLSA records.
This is going to take a few years, with the early adopters feeling
a bit lonely for a while...
If you're willing to be on the bleeding edge and want to help test
code Wietse has not reviewed yet, you can try on a suitable
non-critical system:
$ git clone http://github.com/vdukhovni/postfix
$ cd postfix/postfix
$ make -f Makefile.init 'CCARGS=-DUSE_TLS' 'AUXLIBS=-lssl -lcrypto' 'OPT=' \
makefiles # Add whatever else you need
$ make
$ make upgrade
The default branch is currently "DANE10", it may change in the
future, in which case if you're trying to stay current, you'll need
to checkout "DANE11", ... as they become available.
The documentation for DANE is at:
html/TLS_README.html#client_tls_dane
html/TLS_README.html#client_tls_policy
and various parameters linked from these. The main immediately
usable feature is support for per-destination trust-anchors
(root CA replacements):
html/postconf.5.html#smtp_tls_trust_anchor_file
which you can configure for a set of destinations without waiting
for them to do DNSSEC and TLSA. Otherwise, until more of you deploy
DNSSEC and publish TLSA records, DANE will have negligible impact
on your outbound mail stream.
--
Viktor.
