Questions for PR [1]:
* Regarding this text:
The client MUST NOT use the server-provided retry keys until the handshake
completes successfully. On success, it MUST NOT overwrite the DNS-provided keys
with the retry keys. It MUST use the retry keys at most once and continue
offering DNS-provided keys for subsequent connections. This avoids introducing
a tracking vector, should a malicious server present client-specific retry keys.
... specifically this part: ".. use the retry keys at most once".
Q1: Are you saying the client should persistently remember which public_name
values triggered retry keys? For how long?
Q2: What happens if fronting server A sent retry keys, and the subsequent
transport connection ends up on server B, which also sends retry keys?
--Roelof
---- On Wed, 13 Feb 2019 17:15:57 -0500 Christopher Wood
<christopherwoo...@gmail.com> wrote ----
Hi folks,
PRs [1] and [2] need a little more review before we merge since
they’re non-trivial changes. Please have a look and let the list know
if you have objections with the contents therein. Otherwise, we will
merge them by the end of the next week.
Thanks!
Chris (no hat)
[1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124
[2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125
_______________________________________________
TLS mailing list
mailto:TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
