I concur with MT's proposal
On Wed, Mar 4, 2020 at 3:42 PM Martin Thomson <[email protected]> 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. > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
