The server needs to acknowledge that a Retry happened

[martinthomson]

This should prevent a MitM from generating a Retry without some level of coordination with a server.

Even with this change, the process for managing the use of a third-party DoS screening device can be straightforward. There are a few important tweaks that will ensure that this won't result in troubles:

1. The server can no longer generate Retry itself, it has to rely on the DoS screening device for this. If they both could generate Retry, the one from the server is going to be ignored. As noted in discussions in NYC, if Retry is sent with low probability, this will hard to debug because the event will be very rare.
2. Tokens generated by the server in NEW_TOKEN need to be clearly distinguishable from tokens generated by the DoS screening device.
3. Tokens generated by the DoS screening device need to encode the original destination connection ID in a way that the server can recover it.

Closes #1710, #1486.

[nibanks]

Why is the design such that the client validates instead of the server? Can we not have such a design where the client updates its TP to include the original CID, and the server validates this? It is the one that knows if it expected a Retry or not. In the case of a completely independent DoS protection device, that the server wants to allow for, it doesn't necessarily know the original CID, and could then just generally allow any changes. I just think the server should be the one doing the validation, as it know the deployment state; not the client.

[ianswett]

To clarify, the server can't generate a retry itself IF there's also a DoS device in front of it. If the DoS device is the server, I don't see why that wouldn't work?

[nibanks]

To be specific, the server can't generate a Retry if the DoS device already generated one. If the DoS device is only present some of the time, the those other times, the server can still do it.

[martinthomson]

Why is the design such that the client validates instead of the server?

It creates the right incentives. This way, server implementations can't cheap out and not implement the check or coordination. If servers didn't check, middleboxes could come to rely on them not checking. That leads to Retry coming from middleboxes, which I heard pretty firmly that we don't want.

Given how easy this is to manage with a tiny bit of coordination (Azure could simply publish their scheme for encoding the connection ID into the token, for instance), this scheme seems like the best way to avoid that class of problem.