- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 7 Jun 2018 09:55:53 +0200
- To: Mirja Kuehlewind <ietf@kuehlewind.net>
- Cc: The IESG <iesg@ietf.org>, draft-ietf-httpbis-replay@ietf.org, Patrick McManus <mcmanus@ducksong.com>, httpbis-chairs@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>
Hi Mirja, thanks for reviewing. A few responses below. On Wed, Jun 6, 2018 at 5:08 PM Mirja Kühlewind <ietf@kuehlewind.net> wrote: > 1) sec 5.1: "Multiple instances MUST > be treated as equivalent to a single instance by a server." > What happens if the multiple instances have different values? Does that > generate an error? Or more generally, what if the value is not 1? Someone else picked up on the same thing apparently. The current editor's draft says: "Multiple or invalid instances of the header field MUST be treated as equivalent to a single instance with a value of 1 by a server." > 2) "The server cannot assume that a client is able to retry a request > unless the request is received in early data or the "Early-Data" > header field is set to "1". A server SHOULD NOT emit the 425 status > code unless one of these conditions is met." > Shouldn't actually both criteria be met? Either is what we want. A server might receive a request in early data without the header field. User agents don't add the header field typically. A server might also receive a request on a after the handshake completes (and even in TLS 1.2, that's why we insist that the intermediary know that servers understand this feature) with the header field. > 3) Are there any additional risks/attacks possible with the use of the > "Early-Data" header field or "Too Early" status code? I thought that should be > covered in the security considerations as well... These are strictly mitigation techniques. I don't think that they increase attack surface. They only make stuff fail in circumstances where things might not be safe.
Received on Thursday, 7 June 2018 07:56:27 UTC