On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit <r@nerd.ninja> wrote: > 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? >
No, exactly the opposite. You use the retry key for just the retry and then forget about it. https://mailarchive.ietf.org/arch/msg/tls/xBEHe1_CcYEYinZQHxWGq8vjA0Q 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? > You keep retrying. And hen you hit the text which says: > Clients SHOULD implement a limit on retries caused by "esni_retry_request" or > servers which do not acknowledge the "encrypted_server_name" extension. This is an error-correcting mechanism to avoid deployment risks. If your TLS deployment is so out of sync with itself that: - It deployed ESNI keys in the DNS that your servers do not understand. - Even on a retry to presumably the same IP address, you hit a different server node. - Your load balancer keeps bouncing between different server nodes connections right after each other. - Each of your server nodes believes in a totally disjoint set of ESNI keys.. Then I think giving up and failing the connection is not the end of the world. > > --Roelof > > > ---- On Wed, 13 Feb 2019 17:15:57 -0500 *Christopher Wood > <christopherwoo...@gmail.com <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 > <https://github.com/tlswg/draft-ietf-tls-esni/pull/124> > > [2] https://github.com/tlswg/draft-ietf-tls-esni/pull/125 > > _______________________________________________ > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
