On Thu, Feb 14, 2019 at 1:46 PM Roelof DuToit <r@nerd.ninja> wrote: > > > > ---- On Thu, 14 Feb 2019 13:00:16 -0500 *David Benjamin > <david...@chromium.org <david...@chromium.org>>* wrote ---- > > 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 > > > I understood that part. Let my clarify my question with an example: > > A1. Client uses DNS-provided keys, and server returns retry keys > A2. Client uses retry keys, and everything works.. > A3. Client restarts > A4. Client uses DNS-provided keys, and server returns the same retry keys > as in A1 > A5. Client violates spec by using those retry keys for a second time? > > And what about this example: > > B1. Client uses DNS-provided keys, and server returns retry keys > B2. Client uses retry keys, and everything works.. > B3. Client uses DNS-provided keys, and server returns retry keys > B4. Client violates spec by using those retry keys for a second time? >
Oh, I see. Yeah, that's just a mistake in the text. A5 and B4 aren't meant to be violations, since the client saw the retry keys again. I'll wordsmith that too in the next iteration. > > > >> 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
