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

Re: Spencer Dawkins' No Objection on draft-ietf-httpbis-replay-03: (with COMMENT)

From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 7 Jun 2018 13:36:10 +0200
Message-ID: <CABkgnnXUwuUhA7tfMMD17C7UYJ_wN+LqS-95HjYL7rchN4H-8g@mail.gmail.com>
To: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
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 Spencer, thanks for reading so carefully.  Most of what you have
here, I *think* can be addressed here, along with the changes in the
following PR: https://github.com/httpwg/http-extensions/pull/648

On Tue, Jun 5, 2018 at 8:55 PM Spencer Dawkins
<spencerdawkins.ietf@gmail.com> wrote:
> When I read the list of replay mitigation measures in Section 3, I found myself
> wondering how an implementer would choose among them. The text that follows the
> list is helpful, but MUCH later in the Security Considerations section, I find
>
>   Disabling early data, delaying requests, or rejecting requests with
>    the 425 (Too Early) status code are all equally good measures for
>    mitigating replay attacks on requests that might be vulnerable to
>    replay.
>
> which ISTM would also be helpful guidance.

I've rearranged this section a little.  I realized that there were
really only three points in the list, effectively matching the text
you cite.  The mandatory measures from TLS don't belong.  I've also
added a note that any of the three is good.

> I'm confused about something in this text.
>
> 5.  Extensions for Early Data in HTTP
>
>    Because HTTP requests can span multiple "hops", it is necessary to
>    explicitly communicate whether a request has been sent in early data
>    on a previous connection.
>
> Do you mean "sent in early data on a previous hop", or something else? I could
> guess, but I'm guessing.

connection and hop are synonymous here.  Willy suggested we go with "a
previous hop", which I've done.

> This is a side question - I understand that you're using the absence of the
> Early-Data header field as "not early data", but wondered if there was anything
> about that choice, that would be good for people maintaining the protocol to
> know.

Ideally, we don't add header fields, or change the way that existing
implementations operate.  Since only new implementations send in early
data, those are the ones that get to change what they send.

> Would there ever be an HTTP version with "Early-Data: 2"?

I used to joke about DNT: 2, and even sent that value for a long time.
But that wouldn't be possible: it's defined as invalid.

> I'm wondering why this text
>
>   User agents that send a request in early data MUST automatically
>    retry the request when receiving a 425 (Too Early) response status
>    code.  Such retries MUST NOT be sent in early data.
>
> has automatic retry as a MUST. I see the MUST NOT in the next sentence. Is the
> MUST also required for interoperation?

The idea here was that if you were willing to risk replay, you are
expected to retry.  But I think that we don't need the MUST.  Here's
what I've proposed:

User agents that send a request in early data are expected to retry the request
when receiving a 425 (Too Early) response status code. A user agent MAY do so
automatically, but any retries MUST NOT be sent in early data.

> I'm reading
>
>   A gateway without at least one potential origin server that supports
>    "Early-Data" header field expends significant effort for what can at
>    best be a modest performance benefit from enabling early data.  If no
>    origin server supports early data, disabling early data entirely is
>    more efficient.
>
> "can at best a modest performance benefit" as saying that if you don't have any
> origin servers that support "Early-Data", you still get a performance benefit
> by enabling early data. Am I misreading this?

Yes, you gain a modest advantage in that bytes sent during early data
don't need to count against the congestion window after the handshake
completes.  If the intermediary buffers the requests, they become safe
to send, allowing for more requests (or larger requests) to be sent
within the same congestion window.  As the text says, it's an marginal
gain.

> There are constraints at various places in the specification that require
> server instances to know things about other server instances. To pick one,
> which is the one that made me wonder, but there are more ...
>
> 6.4.  Out of Order Delivery
>
>    In protocols that deliver data out of order (such as QUIC [HQ]) early
>    data can arrive after the handshake completes.  A server MAY process
>    requests received in early data after handshake completion if it can
>    rely on other instances correctly handling replays of the same
>    requests.
>
> Is it obvious how the server would know that? And could a new instance that
> doesn't correctly handle replays of the same requests come into the picture?

It's very common to have a homogeneous cluster - at least in terms of
the software you run - so you might be able to know that all instances
have affordances for marking provenance of requests correctly and
treating them properly.  In re-reading this particular example, this
probably needs better qualification: rather than "if", I've moved to
"only if".  I reviewed the others and they mostly seem OK.
Received on Thursday, 7 June 2018 11:36:46 UTC

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