Viktor Dukhovni:
> 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.
Just like the SMTP conection cache service, the tlsproxy service
must not try to do clever things. It receives TLS requirements,
does a TLS handshake, and returns TLS session properties that can
later be used to create a connection cache index. If it needs to
impersonate a delivery agent, then it gets that nanme from the
Postfix SMTP client.
For obvious scalability reasons, there need to be as many tlsproxy
processes as needed, so we must not assume that one tlsproxy holds
all state for all TLS sessions.
> > 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.
I think this is a required part of the design.
> > 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.
I think I already mentioned that genrating the right lookup keys
is an important part of the solution.
Wietse
