I support the proposal from Viktor. It is important to minimize the involved resource and provide the client the ability to explicitly inform the server its policy.
As explained above, this mechanism comes with no additional complexity and address a full range of applications. See below my comments inline: Yours, Daniel On Tue, Jan 21, 2020 at 4:19 PM Eric Rescorla <e...@rtfm.com> wrote: > I would make several points here: > > 1. RFC 8446 explicitly discourages ticket reuse > (https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we > should not be designing an extension to enable reuse. While it's > potentially true that some applications do not benefit from > non-reuse, creating a set of mechanisms around reuse risks those > mechanisms being used in settings where reuse would be > bad. Moreover. just because at present sending MTAs have weak > privacy properties does not mean that we should bake in this > situation permanently. > Appendix C.4 discourages the re-use of tickets to avoid passive monitoring. This recommendation only applies when privacy is involved, and other use cases exist (VNF, IoT, MTA,...). This is not *potentially* true, this is simply true. These use cases are considered by RFC8446 and thus need be considered in this proposal. > > 2. The additional cost of multiple tickets seems extraordinarily > small, so I am not at all persuaded that there is enough value in > this use case to justify adding new protocol machinery, even > ignoring point (1) above. > > As explained before, the *machinery* is also largely exaggerated. Those for who the cost of generating ticket is so extraordinarily small actually do not need this extension and can generate an extra large number of tickets (at no cost for them). This statement seems to contradict at least the Less ticket waste use case. In addition, saving cost per connection scales the number of connections which is not negligible. 3. If there *is* such value, then you can register your own extension > which allows you to say the orthogonal thing, namely "don't send me > any tickets at all if you are resuming". This would be more > flexible in that you could then say "I would like 10 tickets, but > only if you don't resume". Note that > https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ would > allow you to do this efficiently. > It is unclear to me why, in this case, this would apply specially to Viktor's proposal rather the counter proposal. > > Thus, I would prefer to advance this document as-is. > > -Ekr > > > > > > > > > > > > On Mon, Jan 20, 2020 at 9:54 PM Viktor Dukhovni <ietf-d...@dukhovni.org> > wrote: > >> On Tue, Jan 21, 2020 at 04:03:46PM +1100, Martin Thomson wrote: >> >> > On Thu, Nov 21, 2019, at 14:19, 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. >> > >> > I see that I didn't respond to this. I support David's view. >> > >> > Even the suggestion that clients that resume only request one assumes >> > that clients only want one. The client probably knows better than we >> > do. I would rather say nothing about the number and keep it simple. 0 >> > means 0, 1 means 1, N means N. >> >> The proposal has since been simplified. With 1 meaning 1, 2 meaning 2, >> ..... The only change is that 0 and 255 become special, with 255 meaning >> definitely no tickets, and 0 meaning tickets only if the server sees a >> need a replace the presented ticket. Otherwise, the client has no way >> to request refresh only if needed, and must ask for 1 just in case. >> >> Unnecessary tickets are a waste server and client resources and >> bandwidth, and make external caches "hot" on clients that are perfectly >> fine with a slowly changing series of multi-use tickets. >> >> >> > FWIW, the cost of oversupply is often marginal, depending on >> > circumstances. In a client-speaks-first protocol with no client >> > certificate, the server can occupy the first round trip with tickets >> > and generally gain a performance advantage (as sending more will >> > increase the congestion window in most cases). >> >> This is useless for clients with just a single mult-use slot in their >> ticket cache. Not everything is a web browser. >> >> > Otherwise, there are usually quiescent periods that can be exploited >> > for sending tickets. And tickets are small, and cheap to generate. >> > With one exception: if you are relying on client authentication and >> > packing that into tickets, I'm sorry. >> >> There's no need to exclude valid use-cases. The refined proposal >> is rather non-invasive, and handles this case cost-effectively >> on clients that re-use tickets (and don't use early-data, ...). >> >> -- >> Viktor. >> >> _______________________________________________ >> 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
