Unlike many/most browsers, Postfix makes each TLS connection from a separate
smtp(8) client process.
TLS session reuse is supported via a shared service process tlsmgr(8) which
maintains a cache of
saved sessions for peer destinations that have provided session resumption data
(session tickets,
or just a session id).
Once a session is saved into the session database, it is used by multiple
clients until it
expires (with TLS <= 1.2, resumption typically does not create a new session,
and the same
session remains in the cache).
How should this change with TLS 1.3? The draft says:
Clients SHOULD attempt to use each
ticket no more than once, with more recent tickets being used first.
What does this mean in practice? What happens if Postfix continues to use the
same ticket multiple times anyway? Will servers somehow invalidate the ticket
after first use? Are the consequences of reuse more severe than with TLS 1.2?
To avoid re-use, it would seem that tlsmgr(8) would have to delete the ticket
from the cache after vending it to an smtp(8) client. For the cache to work
at all well, with sessions consistently resumed after an initial ramp-up, it
would seem that the cache would now need to store a list of tickets, rather
than just a single ticket for each destination. If so, that's considerable
new complexity. :-(
I'd need to prepend tickets to the cache slot, rather than replace the cache
slot, and trim tickets from the end if the list of available tickets grows
too long. Then when a client asks for a ticket, pop the first entry of the
list.
This design would have to coexist with the existing support for TLS <= 1.2
session resumption. So some cache slots would be single-instance multi-use,
and others multi-instance single-use.
When resuming with a TLS 1.3 peer, what happens if the peer is behind a load
balancer, and some of the nodes are still TLS 1.2? Does the handshake fail,
or we somehow end-up doing a full TLS 1.2 handshake?
(Postfix will in many cases "see through" load-balancers, because STARTTLS
is preceded by the peer's SMTP banner and EHLO response which include a
notional remote server name, and when that's server-specific, I use a
separate cache entry for each server).
I'll also need to figure out how all of this plays out in the new OpenSSL
1.1.1 code and its "new session" callbacks.
Unlike most other TLS 1.3 changes, this one is not going to be particularly
transparent to the application, unless ignoring the "SHOULD" and just
reusing session tickets works against peer servers and within the updated
OpenSSL "new session" callback implementation.
Obviously, the OpenSSL-specific issues I'll be hashing out elsewhere, just
mentioning that there are API implications to changes in how resumption is
to be handled...
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
