On Thu, Nov 21, 2019 at 11:19:36AM +0800, David Schinazi wrote: > Regarding Viktor's suggestion, I personally believe it would increase the > complexity of the proposal, and I don't see use-cases compelling enough > to warrant that complexity. I would rather keep this proposal as simple as > possible.
Complexity? I don't see it -- and you didn't show it, only asserted it. But the protocol is a bit broken -yes, broken- without that "option", and here's why: the whole point of this extension is to - a) ensure that clients always have the resumption tickets they need, - and b) to reduce ticket issuance to the minimum necessary for (a), and, well... - that means only issuing resumption tickets when the client needs one to replace the one it's using, - and if the client and server are happy with ticket reuse, then it's up to the server to decide when the client's ticket may no longer be reused, - but the protocol as specified can't let the client say "give me a new ticket IFF you won't let me reuse this one any more", - and it doesn't let the server do such conditional issuance because the client might NOT want to reuse and the server can't know that if the client can't tell it. That's the logical chain that leads me to declare this protocol broken. The fix is trivial. It most certainly isn't complex. A plain assertion that it's too complex is not responsive and insufficient to dismiss the WGLC comment. Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
