Viktor Dukhovni:
>
>
> > On Jun 19, 2018, at 3:07 PM, Wietse Venema <wie...@porcupine.org> wrote:
> >
> > Viktor Dukhovni:
> >> On Jun 19, 2018, at 2:38 PM, Wietse Venema <wie...@porcupine.org> wrote:
> >>> 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.
>
> That's my take also, on the timescale of the connection reuse
> maximum TTL.
>
> >> 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.
>
> Yes, but perhaps better to just use the pre-MX policy
> without modification. Thinking ahead to MTA-STS, when
> a first message triggers background MTA-STS policy
> discovery, we might want messages that arrive after
> that's available to immediately upgrade to STS.
smtp_reuse_session() is called if SMTP_MISC_FLAG_CONN_LOAD is set,
whereas smtp_save_session() is called if SMTP_MISC_FLAG_CONN_STORE
is set. These guards are different for a reason.
Therefore we cannot assume that smtp_reuse_session() will be able to
determine the pre-MX policy to be used by for smtp_save_session(),
unless I mis-understand what you mean with pre-MX policy (I assume
the TLS policy based on the nexhop info only).
I'll keep it simple for now. and use an manifest constant for
nexthop-level connection cache lookups and stores. We can refine
the logic later.
Wietse
> This suggests that the base (nexthop-based) level should
> be used and checked. If that changes, we make a new
> connection.
>
> [ In actuality we'll need some new way to enable either or
> both of MTA-STS and DANE, and when both are enabled prefer
> DANE for those MX hosts that have TLSA records, but otherwise
> do MTA-STS if that's provisioned at the remote domain. But
> that's for 2019. ]
>
>
> >> 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.
>
> Instead of a dummy, I think for now just keep the
> level that comes out of TLS policy lookup, before
> DANE messes with it on a per-MX basis.
>
> We could later consider refactoring, so that the DANE
> level always remains unchanged, but is treated as "may"
> dynamically, when no TLSA data accompanies the client
> policy.
>
> --
> Viktor.
>
>
