Don't retry from retry #616
Conversation
draft-ietf-tls-esni.md
Outdated
| Clients SHOULD NOT accept "retry_config" in response to | ||
| a connection initiated in response to a "retry_config". |
There was a problem hiding this comment.
Do we have a little more color to add here?
This is mostly about the case where a retry config is supplied by one server instance, but other server instances don't work. That is a server configuration error, unless the client decided to keep the retry config for too long, in which case it is a signal that the client shouldn't hold on to old state.
Adding that sort of context might make the SHOULD a little more useful.
|
I added some text. |
draft-ietf-tls-esni.md
Outdated
| in this situation is a signal that the server is misconfigured, e.g., | ||
| the server might have multiple inconsistent configurations so that the | ||
| client reached a node with configuration A in the first connection and | ||
| a node with configuration B in the second. If a client does not retry, |
There was a problem hiding this comment.
The previous paragraph also talks about a "retry". But that is an ECH disabled retry.
In this paragraph, based on the context, it is referring to an ECH enabled retry.
Should the client be allowed to perform an ECH disabled retry here? And should anything about that, allowed or not allowed, be noted in this paragraph also?
There was a problem hiding this comment.
I think this is a reasonable question. Updated the text.
Note that I also broke out the requirement to report the error separately as I think it applies to both cases.
|
I had two retry change PRs off the same place and the first one merged. |
This was split off from PR#609. Hopefully this is uncontroversial.