On Thu, Feb 14, 2019 at 2:25 PM Roelof DuToit <r@nerd.ninja> wrote: > ---- On Thu, 14 Feb 2019 15:13:11 -0500 *David Benjamin > <david...@chromium.org <david...@chromium.org>>* wrote ---- > > 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. > > > Could a MITM (the kind that can finish the handshake) set > esni_retry_request every time it sees an unknown record_digest in the ESNI > extension, and essentially use the retry mechanism to subvert the intent of > ESNI? >
It would need to be able to authenticate as the public name for the client to pay any attention to this. The public name is the name of the entity trusted to update the ESNI keys. (Presumably the name of the hosting provider or so.) The point is to give a secure retry signal, in hopes of getting both deployability and security. David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
