Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-02.txt

[Viktor Dukhovni <[e-mail]>]

> On Oct 11, 2019, at 4:55 AM, Martin Thomson <[e-mail]> wrote:
> 
> Yeah, I agree that this is a little thorny.  However, the client asking for one extra and the server vending one more is a relatively small extra expense AND we discourage reuse in the general case.  So, at least from my perspective, this isn't that serious a problem and shouldn't block publication.

In Postfix, multiple SMTP client processes share a 1 slot external
session ticket cache, and expect to re-use tickets until a new one
is issued by the server.  This works poorly with servers that don't
allow re-use, and updating the cache on each connection is rather
wasteful on both ends.

Presently, the Postfix SMTP server assumes clients of the same kind,
and always only issues new tickets *as-needed*.  If clients could
signal their real requirements, that policy would no longer need
to be hard-coded, it would just become a default for clients that
don't send this extension.

Perhaps the solution is to say that clients that don't send the
extension get default application-specific behaviour, possibly
"refresh only as-needed".  If they prefer to always get a specific
number of tickets, they can request that number.

Then I guess I could attempt to honour the extension, and revert
to default behaviour in its absence, making sure that the Postfix
SMTP client either does not ask to send the extension, or invokes
some appropriate OpenSSL interface to ask that it not be sent as
appropriate.

-- 
	Viktor.