Thanks Viktor, On Fri, 2014-10-10 at 21:06 +0000, Viktor Dukhovni wrote: > 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.
I control both server and DNS. I went with:
_25._tcp.mje99.posix.co.za. IN TLSA 3 0 1 {hexxy stuff}
I manage the SSL Certificate - carefully. Exim works in "Ad Hoc" mode...
(ie another Exit chats to mine)... I read the
draft-ietf-dane-smtp-with-dane - which seemed to suggest "3 0 1"... Key
Roll-Overs may be fun -- but I've got about a year before that.
I'm unsure of the middle digit...
0 = Full certificate
1 = SubjectPublicKeyInfo
... doesn't mean very much to me.
I chose "0" as most examples had that - and its the same as for my web
sites... which seem to keep the dnssec validator (CZ-NIC) happy and
green.
Perhaps you could let me know if I fall in that "error rate"
category? :-) I know I'm on unknown territory - I'd appreciate an
understandable reason to change.
> 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.
>
--
Mark James ELKINS - Posix Systems - (South) Africa
[email protected] Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
smime.p7s
Description: S/MIME cryptographic signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
