On Sat, Feb 29, 2020 at 2:28 PM Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> 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. > Hi Viktor, I think that what you bring up here has value, but I do not see it in scope of draft-ietf-tls-ticket-request. The draft as currently written addresses the use-cases that it was scoped to address. I would encourage you to propose another draft with your use-cases, as that would be a great starting point for that discussion. I appreciate your editorial work on draft-ietf-tls-ticket-request and I'm willing to make those editorial changes (assuming the other editors agree), but we shouldn't change the normative text to support an out-of-scope use-case. Thanks, David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
