No. FWIW, we (at my day job) run TLS 1.3 at large scale for server-to-server RPC communication, and have seen no appreciable performance overhead from ticket refresh on resumption.
I also have no objection to Martin's proposal. Kyle -----Original Message----- From: TLS <tls-boun...@ietf.org> On Behalf Of Sean Turner Sent: Wednesday, March 4, 2020 11:07 AM To: TLS List <tls@ietf.org> Subject: [TLS] consensus call: draft-ietf-tls-ticketrequests 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://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtls-2Dticketrequests_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=4Kz5f1xxZ6P7E_YXEhOUWD50NCnQZIkbCRZbqojrJBk&e= [1] https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/18 [2] https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc8446-23appendix-2DC.4&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=N3Qf8xv0MnsGbbTtjHb5U2IuianYB7TQ8a8CXcIS7Gc&e= [3] https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_2cpoaJRushs09EFeTjPr-2DKa3FeI_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=PELoSAnGtZHjPCTcCWS1d0a-Ta0ZLvhHFeFQ8wbagqs&e= [4] https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_-2D7J3gMmpHNw9t3URzxvM-2D3OaTR8_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=Mfbl7bM_Esrm6nALbKFAUwBtA9G-nCrqy7Le2efwdi8&e= [5] https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_tls_FjhqbYYTwzgiV9weeCuxn0tHxPs_&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=pPiiy8g1rqhJ3lj78u9JrggB4p3yo2yHLLV35NPvFrk&e= _______________________________________________ TLS mailing list TLS@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=l2j4BjkO0Lc3u4CH2z7jPw&m=gDDe89teswtnbN_GsYRvrhMURnKf5xGhnqooz8HMQmM&s=sU60CTb3C9iJnQ7Xnnn5xxjDMHWjjccFZybS8IzGCG0&e= _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
