On Sun, Jul 19, 2015 at 11:10:42PM +0200, Eric Rescorla wrote:
> > So indeed it is no longer possible for the client to signal the
> > ability/desire to resume sessions, and servers will generate session
> > tickets absent any indication that the client intends to use them.
> >
> > This does not impose a space penalty on the server, but some CPU
> > and bandwidth may be wasted on clients that don't or can't resume.
>
> Yes.
>
> So my question is whether there are an appreciably large number of servers
> each of which have an appreciably large fraction of *both* caching and
> non-caching clients to make an optimization like this worthwhile (servers
> which only have non-caching or only caching clients can just send
> or not send a ticket as appropriate)
Such a mixture of clients is not at all uncommon with SMTP. Not
all MTAs implement client-side TLS session caches (no such cache
in Exim or Sendmail). However, sending a session ticket either
way is not a major burden for SMTP servers. It would however be
nice to not waste resources doing so, if an appropriate extension
(say the existing one) were used to signal client support.
This is not an absolutely compelling argument in favour of client
signalling, more of an observation that it could be useful.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
