On Thu, Jan 23, 2020 at 01:32:51PM -0600, Nico Williams wrote:
> On Thu, Jan 23, 2020 at 09:43:21AM -0800, Watson Ladd wrote:
> > Sending a new ticket doesn't force clients to store it.
>
> Sure, but if the old ticket will not be accepted again then the client
> will incur a full handshake later. The client doesn't know if the old
> ticket will or will not be accepted again. Extending the protocol to
> have the server signal that bit will require new OpenSSL extensions,
> which is why that is not a sufficiently good response to the Postfix
> issue.
Indeed, not storing the ticket breaks resumption. So I always store the
ticket (actually what OpenSSL hands me is a serializable opaque
SSL_SESSION). For example, when the server allows reuse, but has a
shorter maximum ticket lifetime, its "as needed" new ticket needs to be
stored, in order to replace a stale cached session and start using the
fresh one.
Regardless, I also believe that not applications need or want the
marginal privacy offered by single-use tickets (none for clients
with stable dedicated IP addresses) and it should be possible
in such cases (at effectively zero cost as proposed) to negotiate
reuse in a way that allows servers to handle both types of client.
This would allow Postfix to vend single-use tickets to clients
that request that (e.g. MUAs). Right now the code is statically
optimized for the MTA-to-MTA use-case.
So making reuse *negotiable* would in fact enhance privacy for MUAs on
ephemeral IPs sending sufficiently frequent email (from behind a NAT or
otherwise shared or changing address) to a sufficiently popular
submission server that it is not trivial to link resumed TLS sessions to
a given client.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
