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

Re: Eric Rescorla's No Objection on draft-ietf-httpbis-replay-03: (with COMMENT)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 7 Jun 2018 10:45:36 +0200
Message-ID: <CABkgnnWPFzkVty6piGbA75db40GVXwOXsQ-JKzGN-TwqpXL46g@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: The IESG <iesg@ietf.org>, httpbis-chairs@ietf.org, draft-ietf-httpbis-replay@ietf.org, HTTP Working Group <ietf-http-wg@w3.org>, Patrick McManus <mcmanus@ducksong.com>
Thanks for reviewing ekr,

PR here: https://github.com/httpwg/http-extensions/pull/647

For my co-authors (and the WG, for those who are interested), this
removes a toothless MUST and SHOULD in two places.  I'd appreciate a
second pair of eyes on those changes.

On Thu, Jun 7, 2018 at 9:49 AM Eric Rescorla <ekr@rtfm.com> wrote:
> I think the point you want to bring out here is that this allows you
> to bounce individual requests, as opposed to point #2. In fact, you
> might want to say "at the TLS layer" in point #2.

I added the point about the rejection happening at the TLS layer, and
changed from "a request" to "each request" here.

> S 3.
> >          (Section 5.2), in cases where the risk of replay is judged too
> >          great.
> >
> >      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
>
> This is partly true, but note that the client knows whether it would
> replay it.

Yes, but the willingness of the client to risk replay (and maybe
retry) isn't definitive.  Only the server knows if the request is safe
from replay attack.

For instance, we're likely to be quite aggressive about this in
browsers, so we will sometimes be wrong.

> S 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.
>
> This seems to contradict the claims in the TLS 1.3 security
> considerations about side channels.

I don't think that it does entirely, but it's so aggressively
reductionist, it is effectively misleading.  I've expanded slightly,
and called out to Appendix E.5 from TLS 1.3, which is a much better
way to address this.

> S 3.
> >      A server can limit the amount of early data with the
> >      "max_early_data_size" field of the "early_data" TLS extension.  This
> >      can be used to avoid committing an arbitrary amount of memory for
> >      deferred requests.  A server SHOULD ensure that when it accepts early
> >      data, it can defer processing of requests until after the TLS
> >      handshake completes.
>
> I don't understand this last line. You don't have to defer, so why
> should you ensure that?

Mark, Willy, I'm inclined to cull this paragraph.  It's a hang-up from
the time we thought that deferring was our best defense, I think.
I've included that change in the PR.

> S 4.
> >      By their nature, clients have control over whether a given request is
> >      sent in early data - thereby giving the client control over risk of
> >      replay.  Absent other information, clients MAY send requests with
> >      safe HTTP methods (see [RFC7231], Section 4.2.1) in early data when
> >      it is available, and SHOULD NOT send unsafe methods (or methods whose
> >      safety is not known) in early data.
>
> Is that what browsers plan to do?

That seems unlikely.  Browsers already have an exposure to replay that
is far worse than this.  But browsers are weird and the view of the
working group was that we wanted to document best practice.

> S 5.1.
> >      A server cannot make a request that contains the Early-Data header
> >      field safe for processing by waiting for the handshake to complete.
> >      A request that is marked with Early-Data was sent in early data on a
> >      previous hop.  Requests that contain the Early-Data field and cannot
> >      be safely processed MUST be rejected using the 425 (Too Early) status
> >      code.
>
> I think in order for this to be true you need to prohibit clients
> sending with Early-Data=1

Yes, the middle sentence here is true only if the client doesn't
decide to include the header field, but I'm thinking that it doesn't
matter, and there is no real value in a strict prohibition on use of
the header field.
Received on Thursday, 7 June 2018 08:46:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:15:21 UTC