Viktor Dukhovni:
> On Jun 19, 2018, at 2:38 PM, Wietse Venema <wie...@porcupine.org> wrote:
> >
> > It would not crash, but I don't think it would help.
> >
> > First, the scache is indexed with keys that include the TLS security
> > level for a connection, so that we will never reuse a low-security
> > connection to deliver mail for a high-security destination.
>
> The problem is that with DANE we don't know the security level
> until we're working with a particular MX host. Or alternatively,
> we should save the original "DANE candidate" level for recording
> in the session cache for nexthop entries, and then use the actual
> level and TLS properties for the per-address entries.
That assumes that the TLS policy for a given (delivery agent, nexthop, ...)
is stable, which is a reasonable assumption.
> IIRC the cache key also includes the delivery agent name,
> so we never mix delivery agents with different CA stores,
> TLS policy tables, ...
Right. We trust in belts, suspenders, and paranoia.
> In which case when looking for some connection to the nexthop,
> I think it could be simpler to assume that if the connection
> match the policy when it was recently created (we have a
> connection re-use TTL) then it should still be good enough
> without salting in the TLS details.
Which is the same thing as fixing it to "may" as in your
previous patch.
> Salting in TLS details is of course needed for the per-peer
> address cache lookups, where the same host might serve
> multiple domains.
> So I don't think the below is correct. One might
> argue that my patch should simply leave the TLS
> level alone (rather than set it to "may"), and
> that the cache entry for the nexthop should reflect
> that preliminary nexthop security level, before it
> is potentially modified for MX hosts that lack TLSA
> records...
But then we'd have to keep that preliminary nexthop security level
around until scache_save_mumble are called. It may be clearer to
use a dummy level to indicate that this is not really used as a TLS
level.
Wietse
