On Fri, Oct 10, 2014 at 10:48:46PM +0200, Mark Elkins wrote:
> I've got DNSSEC generally working, how can I get Exim to benefit?
> I've created TLSA records for some web servers... also created a record
> for my mail server. Is there a document describing how to use TLSA
> records? Does 4.84 fully support TLSA yet?
http://tools.ietf.org/html/rfc6698
http://tools.ietf.org/draft-ietf-dane-smtp-with-dane
http://tools.ietf.org/draft-ietf-dane-ops
Bottom line, choose one of:
_25._tcp.mx1.example.com. IN TLSA 3 1 1 {hex encoded sha256 digest of server public key}
or else (for large organizations with their own internal CA):
_tlsa._dane.example.com. IN TLSA 2 0 1 {hex encoded sha256 digest of trust-anchor cert}
_25._tcp.mx1.example.com. IN CNAME _tlsa._dane.example.com.
_25._tcp.mx2.example.com. IN CNAME _tlsa._dane.example.com.
...
The first choice has the advantage of avoiding any unexpected
certificate expiration surprises, and is simplest to operate when
you control both the server and the DNS.
The second choice has the advantage of decoupling server certificate
updates from DNS changes, once the CNAME is published, the trust-anchor
DNS records are managed by the folks operating the corporate CA.
The down-side is that the certs issued by that CA will expire
periodically.
Avoid all other combinations of the (certificate usage, selector,
matching type) triple.
DO NOT publish TLSA records as a fashion statement. If you can't
ensure that the records are correct at all times, it is much better
to not publish than to publish incorrect data.
Of the ~260 domains I have tested, just under 10 had bad records,
this "error rate" is too high. For DANE with SMTP to be successful,
server operators should avoid casual adoption. Do it it right or
not at all.
On the client side, Exim has EXPERIMENTAL DANE TLSA support, it
likely requires a bit more work before it is ready for primetime.
At this time only Postfix has a production-ready DANE TLSA client.
--
Viktor.
