On Fri, Apr 28, 2017 at 11:20 AM, Viktor Dukhovni <[email protected]> wrote:
> > 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? > Shouldn't be. Mostly, it allows attackers to correlate multiple sessions from the same client, which sounds like it's not an issue in your case. 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. :-( > Well, the idea is that the server gives you a new ticket on each handshake, so that you don't have to reuse. 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? > You should get a TLS 1.2 handshake, modulo bugs. -Ekr
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
