Okay, I've dug out the partial work from several months ago for dnssec
outbound from Exim, finished off the core of it, documented it, etc, and
pushed as a "dnssec" branch.
I'm likely to merge this later this weekend, unless someone shouts.
We still need tests for this, but I don't think using stub/fake DNS
inside the binary is sane for checking validation, so this is contingent
upon a revamp of the test suite to handle using testdns.exim.org, and so
is probably contingent upon finding time to set up Vagrant images of the
test suite. I'm ... not likely to have time for that soon. :(
This work only does 'need_dnssec' (and a few smaller bits) on
dnslookup/manualroute/smtp. 'need_dnssec' is "Secure results only".
It lays the groundwork for what I want to do next, which is to add a
Router option "dane". Not sure if that should take a revision
parameter, until dane gets ratified.
So need_dnssec should be rare, for special cases by cooperation and
between consenting name-servers, while DANE becomes the normal approach.
Proposed semantics:
* If "dane" is set, this does not turn on need_dnssec, but if the MX
results are secure, and if _$port._tcp.$host exists with a TLSA
record for any one of the results from the MX lookup, then in the
Transport:
* unless tls_verify_certificates is also set on the Transport, only
usage 2 or 3 of TLSA apply, usage 0 or 1 will be equivalent to
dane not being set
* need_dnssec is coerced on (Router & Transport)
* tls_sni defaults to $host (if not explicitly set)
* hosts_require_tls is coerced on (if not explicitly set)
* tls_verify_hosts is coerced on (if not explicitly set)
* the trust-anchor from the TLSA record is written to
spool_directory/tlsa/$something
* for non-PKIX usages (2,3) we just use the trust-anchor directly in
TLS setup
* for PKIX usages (0,1), we first use the tls_verify_certificates to
confirm a path to the TLSA trust-anchor, and only if that
succeeds, then use the TLSA trust-anchor for TLS setup, just as
for usages 2/3.
Because DANE uses TLSA on the $host resulting from lookup,
no_multi_domain on the SMTP transport should not be needed.
Example configuration:
----------------------------8< cut here >8------------------------------
begin routers
dnslookup:
driver = dnslookup
domains = !+local_domains
transport = remote_smtp
dane
no_more
# ... other local routers ...
begin transports
remote_smtp:
driver = smtp
tls_verify_certificates = /etc/ssl/certs
----------------------------8< cut here >8------------------------------
Does that look sane to folks?
Might also make openssl_options an SMTP Transport option, not just a
main option, for use in the client context. I'm thinking it makes sense
to coerce in `no_sslv2 : no_sslv3`, since it's modern TLS with SNI
anyway.
In another branch somewhere I have mostly-complete code for forcing a
compression block end after SMTP AUTH ... the cut-through stuff means
that needs revisiting, I'm not likely to do that soon.
Thoughts?
-Phil
