On Wed, Mar 4, 2020, at 3:42 PM, Martin Thomson wrote: > 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.
+1 -- I support two separate numbers given these constraints. Best, Chris > > 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 > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
