---- On Thu, 14 Feb 2019 13:00:16 -0500 David Benjamin <[email protected]>
wrote ----
On Wed, Feb 13, 2019 at 7:37 PM Roelof DuToit <mailto:[email protected]> 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?
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:[email protected]> 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:[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
mailto:[email protected]
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
