- From: Willy Tarreau <w@1wt.eu>
- Date: Tue, 25 Jul 2017 07:22:12 +0200
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Kazuho Oku <kazuhooku@gmail.com>, Subodh Iyengar <subodh@fb.com>, Ilari Liusvaara <ilariliusvaara@welho.com>, Mike Bishop <Michael.Bishop@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Tue, Jul 25, 2017 at 02:47:59PM +1000, Martin Thomson wrote: > On 22 July 2017 at 04:02, Kazuho Oku <kazuhooku@gmail.com> wrote: > > > OTOH, if we move the responsibility of setting the `early-data` header to > > the client (and therefore require the client to do the resend), the 4xx > > will need to go to the client, and then the request will travel though the > > entire chain. This means that the client will need to wait for 8 RTTh since > > it started sending the TLS handshake. > > > > That requirement was already present. Though if your suggestion is to > allow an intermediary to retry a request, that's problematic in the sense > that it hides the fact from the user agent. Sure, a user agent accepts the > risk of replay when it sends a request in early data, but that doesn't give > an intermediary a license to retry for it. > > There's probably some way that we can describe rules for retrying at the > intermediary. It does save a round trip between the user agent and > intermediary, and there is some potential value in having intermediaries > repair things. But we lose some of the nicer end-to-end properties by > doing so. In fact I think there are some situations where it can safely be done, specifically if the request was received as 1-RTT, or if the handshake was completed in the mean time because it then becomes equivalent. Probably that we should make a diagram to explain where and when the risk of replay lies and make it more obvious what the intent of the retry is (ie: prove that the request was not tampered with by using a safe connection). Willy
Received on Tuesday, 25 July 2017 05:22:41 UTC