Subject: Adam Roach's Yes on draft-ietf-httpbis-replay-03: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 05 Jun 2018 22:52:38 -0700

Adam Roach has entered the following ballot position for
draft-ietf-httpbis-replay-03: Yes

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

Thanks to everyone who worked on this document. I appreciate its concision and
clarity.

I have one comment that is either quite important or a misunderstanding on my
part, followed by a couple of very minor editorial nits.

---------------------------------------------------------------------------

§5.2:

>  In all cases, an intermediary can forward a 425 (Too Early) status
>  code.  Intermediaries MUST forward a 425 (Too Early) status code if
>  the request that it received and forwarded contained an "Early-Data"
>  header field.  Otherwise, an intermediary that receives a request in
>  early data MAY automatically retry that request in response to a 425
>  (Too Early) status code, but it MUST wait for the TLS handshake to
>  complete on the connection where it received the request.

This seems correct but incomplete.

I believe that we also want to (MUST-level) require the forwarding of the 425
in the case in which an intermediary receives a request from a client in early
data (i.e., no "Early-Data" header field), forwards it towards the origin
(with an "Early-Data" header field), and then receives a 425 response. I
suspect the intention here was to cover that case in the "MUST" above, but
it's not what the text actually says.

---------------------------------------------------------------------------

Presumably, the "Note to Readers" section immediately following the abstract
is to be removed prior to publication?  Please either remove it or add a note
that the RFC editor should remove it.

---------------------------------------------------------------------------

§4:

>  If the server rejects early data at the TLS layer, a client MUST
>  start sending again as though the connection was new.

nit: s/was new/were new/

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 6 Jun 2018 11:01:15 +0200

Hello Adam,

first, thanks for your review.

I'm not sure I get exactly the case you want to cover or what you would
like to adjust. The purpose of what is (possibly poorly) explained in the
original text is to ensure that the following cases are properly covered :

  - client sending a request using early data, intermediary forwarding it
    before waiting for handshake to complete, receiving 425 thus forwarding
    425 to the client to ask it to retransmit without using early data ;

  - client sending a request using early data, intermediary forwarding it
    before waiting for handshake to complete, receiving 425 but having the
    whole request buffered, so it can wait for the handshake to complete
    and then retry without bothering the client since after the handshake
    completes the request is safe.

  - client sending a request using early data, the first intermediary
    forwards it before waiting for handshake to complete, adding an
    Early-Data header field, then a second intermediary receives it,
    passes it to the server which responds 425. In this case the second
    intermediary has no way to wait for a handshake to complete, it must
    return 425 to the first intermediary (its own client). The first
    intermediary now is in either of the two cases above, it may either
    send 425 to the client or retry it by itself if it is able to wait
    for the handshake to complete.

Please let us know if there's still something unclear in this explanation
and/or what part of the original text needs to be adjusted to more clearly
reflect these points.

Thank you!
Willy

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Jun 2018 09:35:28 +0200

Thanks Adam,

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

I think that this is just a misunderstanding, but I'm happy to explore
ways to make this clearer.

> it's not what the text actually says.

It's the opposite, as Willy says.  Let me restate Willy's response
more concisely.:

425 can be forwarded always.
425 is always forwarded if the inbound request contains Early-Data.
425 doesn't need to be forwarded if the request didn't contain
Early-Data; the intermediary can instead absorb the 425 and retry the
request after the inbound connection handshake completes.

That's complete as near as I can tell.

---

From: Adam Roach <[email-masked]>
Date: Thu, 7 Jun 2018 08:12:54 -0500

After your explanations, this makes perfect sense, and upon re-reading the original text, I’m not sure why I misread it. Sorry for the noise.

/a

> On Jun 7, 2018, at 02:35, Martin Thomson <[email-masked]> wrote:
> 
> Thanks Adam,
>