> 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.
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.
