Thanks for clarifying, David! This text reflects my understanding and is fine by my.
Best, Chris On Thu, Nov 21, 2019, at 11:19 AM, David Schinazi wrote: > Hi folks, > > I've chatted with Daniel and Chris offline, and I think there might > have been some miscommunication here. Please allow me to > rephrase what I think is going on, and please let me know if > this accurately represents your views. > > Daniel has a IoT use-case where due to memory constraints, > a client knows it can only handle a certain number of tickets, > and therefore Daniel was wondering if it would make sense to > make the requested number of tickets a required maximum > (as in a RFC 2119 MUST). However, server operators on this > thread have indicated that a MUST would get in the way of > implementing this, due to STEK rotation for example. Daniel > understands this, and is OK with the current mindset of the > document (which is only a hint, not a MUST). Additionally, > Daniel would prefer to see the document move forward. > > In order to try to address Daniel's comments, I attempted > to rephrase the normative section to suggest in more > stronger terms that servers really shouldn't be sending > more than the client's request, but keeping it a SHOULD. > > Here is the PR with the rephrase: > https://github.com/tlswg/draft-ietf-tls-ticketrequest/pull/10 > > Here's a copy of the updated paragraph in the PR: > Clients can use TicketRequestContents.count to indicate the number of > tickets they would prefer to receive. Servers SHOULD NOT send more > tickets than TicketRequestContents.count, as clients will most likely > discard any additional tickets. Servers SHOULD additionally place a > limit on the number of tickets they are willing to send to save > resources. Therefore, the number of NewSessionTicket messages sent > SHOULD be the minimum of the server's self-imposed limit and > TicketRequestContents.count. > > 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. > > Thanks, > David > > > On Wed, Nov 20, 2019 at 2:48 PM Viktor Dukhovni <[email protected]> > wrote: > > On Wed, Nov 20, 2019 at 11:53:08AM +0800, Tommy Pauly wrote: > > > > > > Somebody should try to avoid ending up with N new tickets after > > > > every connection, but in could well be the client. > > > > > > Yes, I think that can and ought to be the client. The client is really > > the > > > only party that can know how many tickets have been "consumed" by > > potentially > > > failed attempts to connect that the server didn't see in time or got > > dropped. > > > > OK, in that case, the proposal, is that on resumption, if the proposed > > extension is *absent*, then the server should generally send just one > > rather > > than any larger default. > > > > If the extension is present, it is up to the client to not blindly ask for > > N > > tickets each time, and generally ask for just one ticket on resumption, > > once it > > has sufficiently many tickets for the desired concurrency level, with each > > parallel thread obtaining one replacement ticket its next connection. > > > > As discussed clients that prefer to reuse tickets, can ask for zero, and > > get 1 > > only as-needed. If the server supports reuse then all is well. > > > > If the server does not support and refuses reuse, then it will issue a new > > ticket each time and may only accept it once, but the client may have a > > single-slot cache. If the client makes only one connection at a time, this > > also works, but if/when its handshakes with the server overlap (a narrow > > window > > of ~1RTT) and two connections attempt to resume with the same ticket, one > > of > > them will end up doing a full handshake, but only when the client and > > server > > applications have incompatible ticket reuse expectations. Some friction > > when the client and server are mismatched is not the end of the world. > > > > So on the whole I think the proposal still works with just a numeric signal > > (tweaked with 0xff == none and 0 == reuse), and the onus to "generally > > send 1" > > on resumption moved to the client (i.e. clients that don't solicit ticket > > reuse > > should request only 1 ticket once they have enough). > > > > -- > > Viktor. > > > > _______________________________________________ > > 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
