Re: Working Group Last Call for Using Early Data in HTTP

On 11/23/2017 08:43 PM, Patrick McManus wrote:
> Hi All - When we met in Singapore we discussed a couple final details
> of the Early Data / Replay draft and indicated we would start WGLC
> after a final(?) update. The authors have made that update and we're
> ready for the LC now.
>
> Please have a look at:
> https://tools.ietf.org/html/draft-ietf-httpbis-replay-02
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dhttpbis-2Dreplay-2D02&d=DwMBaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=mYDf3O_2QDh_tIABq-k-t5_SS4rvNMh9tJ_jFGnJ01U&s=KEGboUba6Rmmy_FnvmuvGglzMFwnQ5U97moEVrOFf_A&e=>
>
> Raise any issues either on the mailing list or in the issues list.
> Statements of support, implementation, or intent to implement to the
> list would also be helpful.
>
> We'll run this for a touch over two weeks, ending the WGLC on December
> 10, 2017. We look forward to your comments :)
>
> -Patrick
>

I wish that we were in a position to make stronger guidance about which
requests are safe to process when received in early data, but given the
breadth of cases in which HTTP is used I am not really sure that we
can.  So, all I really have to offer are some nits.

In section 3, we may want to note the different buffering requirements
between case 2 (just requests) and case 3 (requests and pending
responses, for the HTTP/1.1 case ... which can only occur if pipelining
is in use?).

In section 4,

   If HTTP/2 is selected after
   early data is rejected, a client sends another connection preface

Nitpicking, but "another" is only true when HTTP/2 was used
optimistically in the early data.


In section 5,

   o  The "Early-Data" header field is included in requests that might
      have been forwarded by an intermediary prior to the TLS handshake
      completing.

For cases involving an intermediary, there is not necessarily a single unique TLS handshake; we should disambiguate.  (And I think we really need all TLS handshake(s) between client and current intermediary, inclusive, to have completed.)

In section 6.1, a nit that we have both "isn't certain" and "is uncertain" in different sentences, and probably don't need such a distinction.  (It might also make sense to reorder the SHOULD "disable early data" and "[not send Early-Data: to the origin by doing X or Y]" since the former makes the latter unnecessary if there is only a single intermediary.)



-Ben