> On Jun 19, 2018, at 12:32 PM, Viktor Dukhovni <postfix-us...@dukhovni.org>
> wrote:
>
> DANE context initialization needs to know whether the MX hostname
> is an alias, and was previously only done per-MX. Now there's
> a new call with "iter->rr" still NULL. The code in dane_init()
> is not prepared for that. Without the MX hostname and its DNS_RRs
> it can't decide whether the security level is DANE (MX host has
> TLSA records, ...) or opportunistic TLS.
Connection re-use is primarily per-destination, and only
secondarily per-address, while DANE policy is per MX host,
based on presence or absence of TLSA records for *that* MX host.
At the global level, all we know is whether the nexthop
domain is a *candidate* for DANE, but not whether DANE
will or won't happen.
If we have a cached connection for the same nexthop
domain (and port), presumably it has a recent policy
for one of the MX hosts, and we can use that. And
only do fine-graing policy matching when doing per-host
resumption. Which means that dane_init() could be
optimized out when (iter->rr == NULL)?
That would however imply that a change in policy might
not kick in quite as fast as one might like. A reload
might be needed to make sure that cached connections
for a nexthop with a prior policy are not re-used (will
a reload cause scache to restart?).
--
Viktor.
