On Sun, Mar 1, 2020 at 11:20 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> On Sun, Mar 01, 2020 at 10:39:07PM -0800, Rob Sayre wrote: > > > > Agreed, and strongly so with the last sentence. > > > > None of these messages have addressed the chairs' suggestion: > > > > "Consider adoption of an individual draft that describes an extension for > > hinting ticket reuse. This draft will also discuss the use cases around > > ticket reuse." > > > > What's wrong with this suggestion? Is the concern that it won't be > adopted? > > PR#18 isn't exclusively or primarly about reuse. Rather it addresses a > gap in the design which fails to address the difference in required > tickets between resumptions and full handshakes. > > A client should generally (connection racing aside) ask for just one > ticket when attempting resumption, but will need more than one if > instead a full handshake results. > > But on the reuse side, it would be exceedingly cumbersome to have two > separate extensions for negotiating the requested ticket count. We > should just resolve the issue now: > > - Does TLS 1.3 support ticket reuse in applications that can't > take advantage of and don't need the privacy advantages of > single-use tickets? > I actually don't think this is quite the right question. Rather, the question is: Should the TLS WG produce a Standards Track (Recommended) extension that is designed to facilitate reuse. I believe the answer to this is "no", which is why I was not in favor of your original suggestion (I've already explained why I think your "can't take advantage of and don't need" language isn't quite right, so I won't go into that again). The distinction between Recommended and Not Recommended is the mechanism we have come to for allowing TLS to be extensible in ways that the WG thinks are unwise and I think that that's the right way to handle reuse. With that said, I *do* think that the argument that you might only want 1 ticket when you are resuming has some force, and so I feel somewhat more positive about this more general extension, though I have to think about it more. -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls