Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

[Rob Sayre <[e-mail]>]

On Wed, Nov 20, 2019 at 7:20 PM David Schinazi <[e-mail]>
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