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

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
target."

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