On 03/24/2013 11:42 AM, Phil Pennock wrote:
> 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.
Sounds good to me.
>
> 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. :(
I can do some of the grunt work, but it'll take
me a while, I suspect, to understand what's needed.
>
> 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.
Any implications for OCSP-stapling involvement?
>
> 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?
It looks operable. Since it's a new acronym for people to get used to,
maybe some hint in the syntax (eg "security = dane")? This also
makes future incompatible options simpler...
>
> 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.
Send me a pointer; I'll look into it.
--
Cheers,
Jeremy
