Re: [exim-dev] Propose to Merge: 'dnssec' branch

Top Page
Delete this message
Reply to this message
Author: Jeremy Harris
Date:  
To: exim-dev
CC: jgh
Subject: Re: [exim-dev] Propose to Merge: 'dnssec' branch
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