I agree with Martin that this is unnecessary complexity. In addition, I would note that switching to a new ticket *does* help even if the server is using the same STEK because it improves privacy.
-Ekr On Tue, Jan 21, 2020 at 12:58 AM Martin Thomson <m...@lowentropy.net> wrote: > On Tue, Jan 21, 2020, at 16:54, Viktor Dukhovni wrote: > > There's no need to exclude valid use-cases. The refined proposal > > is rather non-invasive, and handles this case cost-effectively > > on clients that re-use tickets (and don't use early-data, ...). > > I don't find your arguments persuasive. This adds complexity specifically > to address a case that has - in the general case - suboptimal > characteristics, both in terms of forward secrecy and linkability. Whether > or not there are specific cases that might tolerate these suboptimalities, > the complexity and risks are borne by everyone. > > This is clearly a subjective call, so I'll step back now. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
