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

Hi Benjamin,

On Tue, Nov 28, 2017 at 11:54:26AM -0600, Benjamin Kaduk wrote:
> 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 fact I'm wondering if we really need to speak about buffering at all
there. From this point it becomes very specific to the implementation.
I'd rather replace "This may require buffering the responses to preserve
ordering in HTTP/1.1" with something like :

   Note that trying to determine upfront which requests are safe and
   which ones are not in a set of pipelined HTTP/1.1 requests while
   waiting for a handshake can be quite challenging and is therefore
   not recommended, since ordering will need to be preserved in
   responses anyway. An safer solution consists in only processing the
   first safe requests and waiting for the handshake before processing
   unsafe ones.

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

Definitely. Also, I think we're making a special case of the connection
preface but in fact we could rather indicate "the client must send (or
resend) all the HTTP/2 traffic starting from the connection preface as
if the connection was new".

> 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 fact this field is sticky and denotes that at least one intermediary
has seen an early-data request. Proposal :

     o  The "Early-Data" header field is added in requests by any
        intermediary forwarding a request received in early data before the
        TLS handshake with its client completes. Its presence indicates a
        risk of replay along the whole chain from the client to the agent
        receiving it.

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

good point.

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

I don't think so, the former indicates what to do with what was received,
and the later suggests whether or not to use early data to reach the next
hop. However I'd suggest "SHOULD not send the request in early data to the
server".

Thanks!
Willy

Received on Wednesday, 29 November 2017 07:04:47 UTC