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

Thanks Spencer.  I am happy leaving the homogeneous cluster comment
alone here (that stipulation is an obvious extension of what text we
have, in my view), but I've tweaked the pull request with your
suggestions.
On Thu, Jun 7, 2018 at 2:21 PM Spencer Dawkins at IETF
<spencerdawkins.ietf@gmail.com> wrote:
>
> Hi, Martin,
>
> On Thu, Jun 7, 2018 at 6:36 AM Martin Thomson <martin.thomson@gmail.com> wrote:
>>
>> 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
>
>
> High order bit: thanks for the quick response. I have a couple of follow-ups, but everything else is fine, and please do the right thing.
>
> Spencer
>
>>
>>
>>
>> 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.
>
>
> That all makes sense to me. Thanks.
>
>>
>> > 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 understanding that this is about what user agents are likely to do, not what any other part of the exchange thinks they are likely to do (which is what "are expected to" made me think).
>
> If that's so, perhaps something like
>
> When requests sent in early data fail with a 425 (Too Early) response status code,
> user agents are likely to retry the request. A user agent MAY do so
> automatically, but MUST NOT send any any retries in early data.
>
>
> would be helpful. But do the right thing, of course.
>
>>
>> > 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.
>
>
> That makes perfect sense, and adding that detail might help people understand how big (or small) the performance benefit is.
>
> Perhaps something like
>
> 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,
> and that benefit only happens if an intermediary buffers the request.  If no
> origin server supports early data, disabling early data entirely is
> more efficient.
>
>
> would be useful, but do the right thing, of course.
>
>> > 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.
>
>
> That's already an improvement.
>
> So, I was actually thinking about (for example) a homogeneous cluster that has a new server added to the cluster (so I used to know what the other servers in the cluster did, but that answer has now changed).
>
> If the answer is that people don't manage clusters this way (they take an entire cluster out of service, reconfigure the cluster to add a server, and bring it back into service), I understand that there can't be a problem with inconsistent handling.
>
> Do the right thing, of course ...
>
> Spencer

Received on Friday, 8 June 2018 10:06:20 UTC