On Wed, Mar 04, 2020 at 10:04:07PM -0500, Viktor Dukhovni wrote: > On Wed, Mar 04, 2020 at 05:56:49PM -0800, Nick Harper wrote: > > > > The whole point of this discussion is that I [am] looking to avoid > > > the need to define two overlapping extensions solving the same > > > problem. The current extension should and will suffice. > > > > By current extension, do you mean what is currently in > > draft-ietf-tls-ticketrequests-04, which provides no mechanism for > > indicating anything about ticket reuse? If so, I'm happy with that > > resolution. > > No I mean *this* extension, roughly as amended in PR#18, subject > to some further polish, with or without explicit handling for reuse. > > > > We might never "bless" a way to negotiate reuse, fine, but there is > > > definitely no need to go out of one's way to forestall that possibility. > > > > MT's approach of putting two values in the extension and saying > > nothing about reuse, or reiterating the advice in RFC 8446 solves your > > problem for enabling reuse without blessing that use case. > > No it does not, because he specifically emphasised treating 0 in the > resumption count as issue no tickets, whereas PR#18 says that that that > don't support reuse (perhaps all if that's the present consensus, until > such time as reuse becomes specified) need to treat both 0 and 1 as 1.
Is this actually the case, though? If we keep the signal from server to client in the echoed extension, the client will know whether or not the server supports resumption, and thus can ask for the appropriate value 0 or 1 in subsequent handshakes. It seems like this would avoid the trap of alternating full and resumption handshakes that was discussed downthread for the case where client supports reuse but server does not. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
