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

From: Eric Rescorla <[email-masked]>
Date: Thu, 07 Jun 2018 00:49:54 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-httpbis-replay-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-httpbis-replay/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4635

COMMENTS
S 3.
>          basis.
>   
>      5.  The server can cause a client to retry a request and not use
>          early data by responding with the 425 (Too Early) status code
>          (Section 5.2), in cases where the risk of replay is judged too
>          great.

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.

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.

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.

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?

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?

S 4.
>      If the server rejects early data at the TLS layer, a client MUST
>      start sending again as though the connection was new.  This could
>      entail using a different negotiated protocol [ALPN] than the one
>      optimistically used for the early data.  Any requests sent in early
>      data MUST be sent again, unless the client decides to abandon those
>      requests.

This MUST in connection with the "unless the client"... seems
confusing. Perhaps "will need to be..."

S 4.
>      were sent in early data, the request will be processed twice.
>   
>      Replays are also possible if there are multiple server instances that
>      will accept early data, or if the same server accepts early data
>      multiple times (though this would be in violation of requirements in
>      Section 8 of [TLS13]).

To be clear, only the second part of this is in violation

S 5.1.
>      An intermediary that forwards a request prior to the completion of
>      the TLS handshake with its client MUST send it with the "Early-Data"
>      header field set to "1" (i.e., it adds it if not present in the
>      request).  An intermediary MUST use the "Early-Data" header field if
>      it might have forwarded the request prior to handshake completion
>      (see Section 6.2 for details).

I don't actually see these details, so perhaps this can be rewritten
more clearly?

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

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Jun 2018 10:45:36 +0200

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.

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

> This is partly true, but note that the client knows whether it would

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.

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

> I don't understand this last line. You don't have to defer, so why

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.

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

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

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 7 Jun 2018 11:05:03 +0200

> second pair of eyes on those changes.

I really like the better wording in your new version. It's clearer in
my opinion about the intents and goals.

> I've included that change in the PR.

I agree. Some might decide that whatever they process is safe for early
data and that they don't want to defer.

> matter, and there is no real value in a strict prohibition on use of

In fact if the client sends the Early-Data=1, it will prevent the server
from waiting for the handshake and will force it to either process the
request or respond 425, just as if an intermediary had added this
Early-Data=1 and used 0-RTT again. Though I cannot find any beneficial
use case for this, we cannot rule out that some people see some value
in doing this.

Cheers,
Willy

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 7 Jun 2018 18:27:58 +0200

On Thu, Jun 07, 2018 at 11:21:28AM -0500, Benjamin Kaduk wrote:
> On Thu, Jun 07, 2018 at 11:05:03AM +0200, Willy Tarreau wrote:
> I agree that the SHOULD is not needed, but wonder if there is value
> in retaining some statement along the lines of "servers that choose
> to buffer have a knob available to control how big of a buffer they
> need to reserve".

While usually I wouldn't suggest such apparently trivial stuff, here
we're speaking about having such a buffer available at a very unexpected
moment or place in an implementation, and I think that placing such a
warning regarding the impacts of using early data in existing code, and
explaining how to adjust it could save a number of people from trying and
wasting their time if it's not designed at all to accept this.

It's not critical though, but I definitely think it's easier to find
in an HTTP-related spec than in the TLS one for most HTTP implementers.

Regards,
Willy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Jun 2018 12:10:13 +0200

> wasting their time if it's not designed at all to accept this.

This isn't an easy answer, because the amount of space you need
depends on how you buffer as well as a bunch of other factors.  For
instance, if you buffer into parsed structures, accounting for
buffering is not directly related to the number of octets you receive.

And there is the mix of traffic you might expect to receive, if you
get lots of requests that would be considered safe, maybe allowing for
a larger buffer is OK if you are willing to send 425 in the case that
you run out of space.

At some point we have to leave it to people to do some engineering and
I think that this is one of those cases.  The advice we would give
would be at best imperfect, but probably quite wordy.  Better to deal
with this on a blog posting, server configuration documentation, or
something else.