Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

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
> <davidben@chromium.org <davidben@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
>> <christopherwood07@gmail.com <christopherwood07@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
>>
>
>