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

[Roelof DuToit <[e-mail]>]

---- On Thu, 14 Feb 2019 15:13:11 -0500 David Benjamin <[e-mail]> wrote ----






On Thu, Feb 14, 2019 at 1:46 PM Roelof DuToit <mailto:[e-mail]> wrote:









---- On Thu, 14 Feb 2019 13:00:16 -0500 David Benjamin <mailto:[e-mail]> wrote ----







On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit <mailto:[e-mail]> 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?









 







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 <mailto:[e-mail]> 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:[e-mail]

https://www.ietf.org/mailman/listinfo/tls






_______________________________________________

TLS mailing list

mailto:[e-mail]

https://www.ietf.org/mailman/listinfo/tls