On Thu, Nov 21, 2019 at 11:19:36AM +0800, David Schinazi wrote:
> 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).
I agree. I am also looking for servers to not oversupply clients with excess
tickets, and not expecting any obligation on the server to return as many as
requested.
> Additionally,
> Daniel would prefer to see the document move forward.
I am also keen for the document to move forward, it adds a very useful signal
from the client to server.
> Regarding Viktor's suggestion, I personally believe it would increase the
> complexity of the proposal,
There is no additional complexity in the protocol. The same extension
structure is sent, and its interpretation is almost identical. The
only difference is:
* 0xff is the new zero (client declines use of tickets)
* 0x00 is a new value to signal optional (reusable) tickets
as-needed.
* 0x01-0xfe are interpreted exactly as in the original draft!
(But clients should be *encouraged* to send 1 on resumption).
> and I don't see use-cases compelling enough to warrant that complexity. I
> would rather keep this proposal as simple as possible.
There are millions of Postfix MTAs that only support a single slot ticket
cache, and where a server that sends more than 1 ticket causes multiple writes
to the single-slot cache (hence part of the enthusiasm for the extension), but
also writes to the cache (which is an external Berkeley DB) create excessive
overhead. Also the server wastes CPU and network bandwidth sending unwanted
tickets, but the client must not simply decline tickets, since it wants stale
tickets to be refreshed.
I have a hard understanding why a relatively simple proposal that meets the
needs of many deployed MTAs is not a valid use-case.
If you don't feel like authoring the text to make the requested change,
I can probably contribute a pull request. At this time the details
seem to have been ironed out in principle.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
