On Wed, Nov 20, 2019 at 7:20 PM David Schinazi <dschinazi.i...@gmail.com> 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. > This sounds pretty close to the "MAY option" I sent on Oct 2 here: https://mailarchive.ietf.org/arch/msg/tls/YogBUOC0ZujSAxHVp8H0oIjJm3Y The latter half of the patch's paragraph still uses "SHOULD" interoperability requirements to remark on quality-of-implementation issues, rather than just explain them. That's not great, but also not a dealbreaker. thanks, Rob
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
