On Sat, Feb 29, 2020 at 12:40:43PM -0800, David Schinazi wrote:
> I like the editorial changes in your PR #18, as they do a good job of
> explaining things.
Thanks! I could add a bit more text to guide client implementations on
how to update their ticket caches in response to tickets from the
server, but first wanted to see how this first cut will be received.
And perhaps there's a risk of explaining too much.
> However, I don't think we should add a second
> count in this extension. Allowing ticket reuse is not something we
> have consensus for in the WG, and I would like to see this discussion
> happen in the TLS WG, but not preventing this draft from moving
> forward.
But the second count is not just or even primarily for reuse, it is also
useful for the non-reuse case as explained in the new text. The fact
that it then possible to cleanly express reuse is a byproduct, and I
also don't mean to encourage reuse in general, but it does have
non-trivial applications, where the privacy impact is zero (no client
privacy is possible or desirable).
The TLS WG can maintain a strong focus on *enabling* privacy, and a
strong recommendation that applications need to take privacy into
account, but WITHOUT forcing pointless privacy-related counter-measures
down everybody's throat, whether you need it or not.
Ignoring the needs of market segments other than the principal one
of browser-to-website is IMHO not something that the TLS WG should
do. The browsers are perfectly capable of not doing reuse, and
even if some misguided client erroneously offers reuse, the server
can decline. Ticket reuse requires the coöperation of both client
and server, by which point a reasonable position to take is that
it is their choice to make.
--
Viktor.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
