Auteur: Phil Pennock Date: À: Jeremy Harris CC: exim-dev Sujet: Re: [exim-dev] Preliminary dane_require_tls_ciphers support
On 2018-03-29 at 10:33 +0100, Jeremy Harris via Exim-dev wrote: > I'm unsure about the philosophy of the interface; having one option
> override another. You mentioned "complex expansions" before in the
> discussion but without detail. I assume that's the same consideration
> as "lots of conditional logic" above. Was that discarding the solution
> of dnsdb-lookup expansions selecting values for the original
> tls_require_ciphers option?
We already just ignore so many TLS options when DANE is determined to be
in effect, so it seemed cleanest to make it easier to have a different
option, both for the code-base and for postmasters maintaining configs.
Otherwise, we're looking at a new variable exposed once DANE is seen.
There, `tlshigh` is a possible key from a "K1=V1 K2=V2 K3=V3" list
populated from other sources, letting me say "gmail.com: tlshigh=yes"
and so forth.
Clearly, I am capable of changing that to use a variable, but ... this
is security, and complexity is the enemy of security. If we require
everyone to do this, then an uncomfortably large percentage of installs
will get it wrong.
If we say "DANE will use this other option by preference, just set that
to something strong", that's much harder to get wrong. We can have an
easy win for most people, while those who want manually
configured/derived per-domain properties can continue to do so.
It's a judgement call, but I think here, DANE-specific is the way to go.
Off-list, there was a suggestion of renaming it to not mention DANE but
be for whenever TLS is mandatory. I think leave that for a future
reconfig, because at present the Exim way would be to either have two
Routers, with distinct smtp Transports, with different TLS configs on
the two transports, the "hosts_require_tls = *" one requiring better
ciphers, or to use address_data for dynamic property binding, as I do.
> I'd prefer testing was in place before merge if at all possible.
> Certainly in place before it hits a release.
We have improved here, mostly thanks to you. Thank you. :)
> I'll have a go, planning to push into the dane_require_tls_ciphers
> branch.