Wietse Venema:
> 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.
>  
> > [...]  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.

And that is what I will try to implement: a dummy security
level for nexthop-level connection cache lookup keys.

        Wietse

Reply via email to