I have a third option (mu?) which differs from previous proposals. I have been somewhat convinced by the arguments about how resumption is different and can tolerate the complexity of the additional counter. That is, endpoints can request replacement of consumed tickets (1 for when a connection attempt succeeds, N if they race N connections and only keep one; 1 + M if they want to replace M wasted tickets from M previous failed connection attempts).
The text about reuse in PR 18 is not good, however. (PR 18 is also very wordy, but that's something I will leave to the editors of the draft.) I can live with a solution that has two numbers, but only on the understanding that 0 means "no tickets". That means no text on reuse, except to discourage it. It means implying that resumption=0 means that the client plans to initiate a full handshake in future rather than explicitly endorsing reuse. As Russ mentions, we might cite the relevant sections of RFC 8446 when it comes to reuse, but for me that would have to be in the context of saying not to do that. On Thu, Mar 5, 2020, at 03:06, Sean Turner wrote: > one more time ... > > All, > > The purpose of this message is to help the chairs judge consensus on > the way forward for draft-ietf-tls-ticketrequests. The issue at hand is > whether the client-initiated ticket request mechanism [0] should be > modified to add support for ticket reuse, see [1] lines 160-214. As we > see it, the way forward involves either one draft or two. To that end, > we would like your input (YES or NO) on the following question by 2359 > UTC 18 March 2020: > > Must the ticket reuse use case be addresses > in draft-ietf-tls-ticketrequests? > > Full disclosure: RFC 8446 recommends against ticket reuse to help > protect clients from passive observers correlating connections [2]. The > PR supports ticket reuse for use cases for a server-to-server > connection that has fixed source addresses and no connection racing; if > adopted the WG will need to ensure that the security considerations are > properly documented. > > Note: There have been at least three threads on this draft [3][4][5]. > Please, let’s try to avoid re-litigating the points made therein. > > Joe & Sean > > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-ticketrequests/ > [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18 > [2] https://tools.ietf.org/html/rfc8446#appendix-C.4 > [3] https://mailarchive.ietf.org/arch/msg/tls/2cpoaJRushs09EFeTjPr-Ka3FeI/ > [4] https://mailarchive.ietf.org/arch/msg/tls/-7J3gMmpHNw9t3URzxvM-3OaTR8/ > [5] https://mailarchive.ietf.org/arch/msg/tls/FjhqbYYTwzgiV9weeCuxn0tHxPs/ > _______________________________________________ > 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
