> On Mar 21, 2018, at 10:48 AM, Wietse Venema <wie...@porcupine.org> wrote:
>
>> It is probably time to refactor the original Postfix 2.11 DANE internals
>> to look a lot more like the new DANE API in OpenSSL 1.1.0, which should
>> serialize a bit more easily.
>>
>> One complication is that we often have more than one smtp(8) delivery
>> agent in master.cf, and different delivery agent instances may have
>> different settings for smtp_tls_CAfile and smtp_tls_CApath, different
>> cipher requirements, .... And yet I don't think we'd want a separate
>> per-agent-instance proxy.
>
> I think that this (sharing the same tlsproxy endpoint with connections
> that have different TLS profiles) is an optimization that can be added
> later.
I failed to make myself clear. I was not looking for such an optimization.
On the contrary, I was noting that we want strong separation of the TLS
configuration and cache handles per-service (transport). This is because
the acceptable ciphers, CAs, protocols, client certificates, ... can vary
between transports, so each transport gets its own SSL_CTX configuration.
My point was that we'd still want a single proxy service, so it will need
to be aware of the connecting transport name, and configure a suitable
SSL_CTX when that name is seen for the first time. Session resumption
would also need to convey the delivery agent name to tlsmgr(8) so that
we don't resume sessions from the wrong transport, which might not have
all the desired properties.
This makes the proxy design a bit more difficult, because it needs to take
on multiple TLS personalities, depending on the connecting delivery agent.
Sufficiently recent OpenSSL versions (IIRC 1.0.2 is sufficient) could make
some of this easier, because the "CONF" (or NCONF) API allows most of the
SSL settings to be configured together in a designated "section" of an
".cnf" (ini) file, freeing Postfix from the need to support an ever-growing
list of OpenSSL configuration settings. With that each SSL_CTX would just
be configured from a separate "section", but for backwards compatibility
we'll still need to support our "legacy" smtp_tls_mumble parameters...
(OpenSSL 1.1.1 has new key types for Ed25519/Ed448, a new cipherlist for
TLS 1.3, new as of 1.1.0 min/max TLS protocol settings, ... and tracking
all these with new Postfix features is starting to look silly).
> The implementation is obvious: store one connection under multiple
> connection cache lookup keys, where each lookup key encodes some
> set of TLS properties.
Perhaps, but that's not the goal at this time.
> Right now, the SMTP connetion cache already stores one connection
> under multiple keys: one for destination, and one for MX host.
Yes, and this could be useful in some cases. The hard part is
putting exactly the right bits into each key, so that we don't
reuse a connection that does not match the desired policy, making
multiple such keys where applicable is indeed not difficult.
--
Viktor.
