First off, thanks for the lively discussion on ticket reuse! I think it's a valid use case and something that should continue to be discussed.
However, for the purposes of the WGLC for this draft, draft-ietf-tls-ticketrequests, it may be best to separate the conversation. It seems that the negotiation of ticket reuse would be best served by another document that could be adopted by the WG. The ticket request document, as it was adopted, was specifically a mechanism to request multiple tickets so as to *avoid* ticket reuse. This is stated several times in the use cases (section 2) and security considerations (section 5). While this does not preclude a future extension that negotiates ticket reuse, I believe, as an author, that enabling ticket reuse is out of scope of this particular document. Best, Tommy > On Jan 23, 2020, at 1:01 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
