On Tue, Jan 21, 2020 at 01:17:59PM -0800, Eric Rescorla wrote:
> I would make several points here:
>
> 1. RFC 8446 explicitly discourages ticket reuse
> (https://tools.ietf.org/rfcmarkup?doc=8446#appendix-C.4). so we
> should not be designing an extension to enable reuse. While it's
> potentially true that some applications do not benefit from
> non-reuse, creating a set of mechanisms around reuse risks those
> mechanisms being used in settings where reuse would be
> bad. Moreover. just because at present sending MTAs have weak
> privacy properties does not mean that we should bake in this
> situation permanently.
Indeed I agree that ticket reuse is often undesirable, and expect that
it will be avoided in many cases. So I am somewhat sympathetic to the
above as a starting point for the analysis.
That said, I don't see that making reuse easier to negotiate is likely
to create significant opportunities for misuse.
- Both the client *and* the server would need to opt-in to reuse.
* Even if the client asks for reuse, the server can invalidate
the old ticket (something it would need to be able to do
already to ensure non-reuse) and send a fresh one anyway.
The client would have to replace the old with the new, since
it has to assume that the old is now likely invalid.
* Even if the server is willing to reuse, if the client asks
for a new ticket, the server has to assume the client has
a single-use cache, and should vend a new ticket.
so it takes bilateral coordination to arrive at reuse, and
so accidental reuse in applications where it is inappropriate
requires errors on both ends.
> 2. The additional cost of multiple tickets seems extraordinarily
> small, so I am not at all persuaded that there is enough value in
> this use case to justify adding new protocol machinery, even
> ignoring point (1) above.
Postfix has a shared cache (indexed by destination domain+mx host) for
multiple independent processes racing to use the cache to make remote
SMTP connections.
Frequent writes to that cache create measurable overhead and still don't
prevent reuse. Transmission of unnecessary tickets is also wasteful of
network and other server resources.
Erasing tickets on first use would be unwise, most existing servers will
not presently return a fresh ticket on resumption.
> 3. If there *is* such value, then you can register your own extension
> which allows you to say the orthogonal thing, namely "don't send me
> any tickets at all if you are resuming". This would be more
> flexible in that you could then say "I would like 10 tickets, but
> only if you don't resume". Note that
> https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ would
> allow you to do this efficiently.
This is an interesting idea, but how would the two extensions interact?
And wouldn't that interaction add more complexity? By hypothesis
clients that are willing to reuse tickets don't really need more than
one at a time. Is there a clear use case for multiple concurrent
reusable tickets.
> Thus, I would prefer to advance this document as-is.
Thanks for the substantive response. Much appreciated. I hope you're
willing to address the above reaction, I am trying to find common
ground that addresses your concerns and mine.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
