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
mje@??? Tel: +27.128070590 Cell: +27.826010496
For fast, reliable, low cost Internet in ZA: https://ftth.posix.co.za
