W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2018

Re: Benjamin Kaduk's Yes on draft-ietf-httpbis-replay-03: (with COMMENT)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 5 Jun 2018 14:15:28 +0200
Message-ID: <CABkgnnV-XhFDb-xDFbv7hPWy65MLEzyfCBuSjrnG4e-xTPusSw@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
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>
Thanks for the comments Ben,

There's a PR here: https://github.com/httpwg/http-extensions/pull/645

On Mon, Jun 4, 2018 at 6:09 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> Section 3
>    For a given request, the level of tolerance to replay risk is
>    specific to the resource it operates upon (and therefore only known
>    to the origin server).  In general, if processing a request does not
>    have state-changing side effects, the consequences of replay are not
>    significant.
> It seems that even the size of the reply is potentially a side effect, though
> it's unclear how significant of an effect (or side channel) it is.

I think that the emphasis on processing here remains appropriate.  We
do cover the possibility of other types of leakage in the first
paragraph of the security considerations:

"In addition to those side effects, replays and retries might be used
for traffic
analysis to recover information about requests or the resources those requests

Variations in response size are already a source of information
leakage, so it's not really something that is uniquely enabled by
replay attacks on early data. It's arguably worse in the sense that
there are now potentially more than one response to compare.  However,
where it is made worse, that is most likely as a result of the
processing of the request so that the state of resources changes.
Received on Tuesday, 5 June 2018 12:16:04 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:59 UTC