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

From: Patrick McManus <[email-masked]>
Date: Fri, 24 Nov 2017 02:43:38 +0000 (UTC)

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

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

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Nov 2017 14:04:17 +1100

For the record, I'm aware of implementations in Firefox, haproxy, and
h2o.  Others have expressed the intent to do so, but I'll let them
speak for themselves to avoid me misrepresenting that intent.

On Fri, Nov 24, 2017 at 1:43 PM, Patrick McManus <[email-masked]> 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:

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 24 Nov 2017 12:27:59 +0900

Hi,

I'd like to thank the authors for working on the draft. H2O already
implements this draft, and I am looking forward to see this becoming a
standard soon.

That said, I have one question.

Section 4 has the following paragraph.

> An intermediary MUST NOT use early data when forwarding a request unless
early data was used on a previous hop, or it knows that the request can be
retried safely without consequences (typically, using out-of-band
configuration).  Absent better information, that means that an intermediary
can only use early data if the request either arrived in early data or
arrived with the "Early-Data" header field set to "1" (see Section 5.1).

Could I ask why an intermediary is allowed to forward early data if it "was
used on a previous hop"?

Shouldn't an intermediary wait for the handshake completion or send 425 in
case it is unsure if the request can be retried safely?

My understanding is that the intent of the draft it to make use of
early-data an opt-in feature from server's perspective. This guidance for
the intermediary seems to contradict with the principle.

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Nov 2017 04:48:55 +0100

Hi Kazuho,

> Could I ask why an intermediary is allowed to forward early data if it "was

It's simply because there is a guarantee that either an intermediary before
it or the client will be able to deal with 425 if one such happens.

> the intermediary seems to contradict with the principle.

Not at all. What matters is that if the server is not willing to serve a
request coming as early data, it will send a 425 inviting the client or
any intermediary to resend without early data. So if a middle agent decides
to use early data to join the server, it needs to be certain either to be
able to retry itself, or that someone else will retry for it. Receiving
a 425 in this case with the proof that another agent will retry is enough.

Hoping this helps,
Willy

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 24 Nov 2017 12:57:33 +0900

Hi Willy,

> it or the client will be able to deal with 425 if one such happens.

Thank you very much for the clarification. Now I understand.

The assumption I missed is that by enabling the intermediary to reconnect
with 0-RTT (through the use of EarlyDataIndication is NewSessionTicket
message) the origin server is opting-in to use early data.

-- 
Kazuho Oku

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 24 Nov 2017 05:07:11 +0100

> message) the origin server is opting-in to use early data.

Yes, and if I remember well, you were the first one requesting to allow
this as it was not covered by the initial proposal :-)

Willy

---

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Nov 2017 16:49:14 +1100

> message) the origin server is opting-in to use early data.

:) Oddly enough, the server accepting early data actually makes this a
tiny bit safer.  If the intermediary accepts early data and forwards
the request to a server on a connection that doesn't allow 0-RTT, then
the intermediary has to hope, guess or somehow know that the server
will look at the Early-Data header field.  This way, it knows that the
server will know about Early-Data.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 24 Nov 2017 10:03:10 +0000

I think this is a useful mitigation draft but am concerned that
there's a bit of arm-waving at it's core. Given that people are
(sadly IMO) super-keen about using 0rtt, and this draft is a
harm-reduction effort, I can accept that we may end up having to
live with some arm-waving but I'd like to ask about one bit of
that.

(BTW: Apologies if this was covered in previous list discussion,
if so, pointing me there is a fine answer and I'll try not to
cause any more regurgitation:-)

Section 3 says:

  "It is RECOMMENDED that origin servers allow resources to explicitly
   configure whether early data is appropriate in requests.  Absent such
   explicit information, they SHOULD mitigate against early data in
   requests that have unsafe methods, using the techniques outlined
   above."

I don't get why that SHOULD isn't a MUST. Can you explain why
it'd be ok for an origin server to allow unsafe methods in early
data for all resources that aren't explicitly indicated as being
actually-safe? (I don't see how an origin server could be selective
for the unsafe resources for which there's no config, hence asking
about all resources.)

I'm also not entirely clear what you mean by "mitigate" here. If
mitigate meant reject it'd be clear, but if "mitigate" means "do
whatever you want to handle that" then the entire paragraph starts
to look like weasel words. I assume that you mean one or more of
items 1-4 from earlier in the section. If so, I'm afraid that does
seem to amount to the latter "do whatever you want" kind of guidance.
Is it really not possible to be more specific here?

As a separate comment, the draft is a little vague about the TLS
role of the intermediary or gateway and whether or not those mean
the same thing always. I read it as saying that intermediary and
gateway are synonyms (from the TLS POV) and that the intermediary
or gateway is the TLS server in all cases. If that's a mis-reading
then it might be worth a bit more clarification. (And if I've got
that wrong, then I don't understand how that entity adds an HTTP
header field in section 5.1 for sure:-)

Cheers,
S.

---

From: John Mattsson <[email-masked]>
Date: Sat, 25 Nov 2017 06:44:16 +0000

Read this for the first time. Well-written and useful document.

- Abstract: “This document explains the risks of using early data for HTTP ...”
Very little explanations of risks in the document. I think more explanation and maybe some examples would be helpful for the readers of this document.

- Section 1: “one or two round trip delay”
Should this be “one or two round trip delays”?

- Section 2: “concatenated with other application”
Should this be “concatenated with other application data”?

- Section 1: “The primary risk of using early data is that an attacker might capture and replay the request(s) it contains.”

I think the it would be very good to explain what replay means in this case, especially as the reader might be someone without detailed knowledge of TLS 1.3. While replay in some cases means more than duplication, replay in normal language means duplication and anti-replay are in most cases synonym with mechanisms mitigating duplication. I suggest something like:

 “The primary risk of using early data is that an attacker might capture and replay the request(s) it contains. The attacker might delay, reorder, and/or duplicate requests.”

- Section 3: “TLS [TLS13] mandates”
Doesn’t TLS 1.3 says “SHOULD implement either the single-use tickets or ClientHello recording techniques”?

- Section 3: “It is RECOMMENDED that origin servers allow resources to explicitly
configure whether early data is appropriate in requests.  Absent such
explicit information, they SHOULD mitigate against early data in
requests that have unsafe methods, using the techniques outlined
above.”

“unsafe methods” -> “not safe from side-effects” following the reason above.

Agree with Stephen Farrell that something is missing here. I would suggest something like:

“It is RECOMMENDED that origin servers allow resources to explicitly
configure whether early data is appropriate in requests.  Absent such
explicit information, they SHOULD mitigate against early data in
requests not safe from side-effects, using the techniques outlined
above. Absent explicit information and mitigations, origin servers
MUST NOT accept early data in requests not safe from side-effects.”

/John

On 2017-11-24, 11:12, "Stephen Farrell" <[email-masked]> wrote:

    
    Section 3 says:

    

    Cheers,
    S.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Nov 2017 09:52:02 +1100

Does this help?

It is RECOMMENDED that origin servers allow resources to explicitly configure
whether early data is appropriate in requests. Absent such explicit information,
origin servers MUST either reject early data or implement the techniques
described in this document for ensuring that requests are not processed prior to
TLS handshake completion.

-- https://github.com/httpwg/http-extensions/pull/428/files

And I agree that the role thing could be clearer:
https://github.com/httpwg/http-extensions/pull/429

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Nov 2017 10:06:34 +1100

> Very little explanations of risks in the document. I think more explanation and maybe some examples would be helpful for the readers of this document.

Does this work better?

Using TLS early data creates an exposure to the possibility of a replay attack.
This document defines mechanisms that allows clients to communicate with servers
about HTTP requests that are sent in early data. Techniques are described that
use these mechanisms to mitigate the risk of replay.

-- https://github.com/httpwg/http-extensions/pull/430/files

> Should this be “one or two round trip delays”?

I think that in context this is grammatically correct.

> Should this be “concatenated with other application data”?

Yes.

>  “The primary risk of using early data is that an attacker might capture and replay the request(s) it contains. The attacker might delay, reorder, and/or duplicate requests.”

I think that replay in this context is specifically only means
duplication.  Delaying and reordering are risks that are assumed when
requests are put on different connections, and more importantly, delay
and reorder are not new risks here (they are possible with any
combination of HTTP and TLS versions).

> Doesn’t TLS 1.3 says “SHOULD implement either the single-use tickets or ClientHello recording techniques”?

It goes a lot further than that.  It mandates the use of anti-replay,
though it more strongly recommends those particular techniques.

> “unsafe methods” -> “not safe from side-effects” following the reason above.

I've rewritten that text in response to Stephen.  That removed the
"unsafe" bit.  See https://github.com/httpwg/http-extensions/pull/428

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 28 Nov 2017 11:54:26 -0600

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

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Nov 2017 08:03:29 +0100

Hi Benjamin,

> responses, for the HTTP/1.1 case ... which can only occur if pipelining

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.

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

> 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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 29 Nov 2017 20:20:51 +1100

PR here:

https://github.com/httpwg/http-extensions/pull/440

>    first safe requests and waiting for the handshake before processing

That seems like too much to me.  How about we remove the offending
sentence.  The need to buffer is implicit.  Also, there is some
question about order preservation with pipelining, so maybe we can
instead agree that pipelining isn't important enough to waste text on.

> if the connection was new".

Again, removing the sentence seems to be sufficient.  We already say
"If the server rejects early data at the TLS layer, a client MUST
start sending again as though the connection was new. "

>> handshake(s) between client and current intermediary, inclusive, to have

This was addressed in https://github.com/httpwg/http-extensions/pull/429

The extra detail Ben proposes is not really necessary for what is a
summary and is included elsewhere.

>> different sentences, and probably don't need such a distinction.
[..]
> hop. However I'd suggest "SHOULD not send the request in early data to the

I've proposed a reword in the PR.  The first sentence now talks about
requests.  The second is now a new paragraph that talks about the
relative merits of enabling early data if origin servers don't support
the header field.

BTW, it's not MUST disable because there are - at least in theory -
minor performance benefits to a gateway supporting 0-RTT even if an
origin server does not understand the feature.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Nov 2017 10:28:01 +0100

> instead agree that pipelining isn't important enough to waste text on.

I totally agree. As I mentionned in the issue tracker, we need to keep
in mind that all this is an optimization and we need to stay pragmatic :
anything becoming complicated isn't worth the trouble, and in the end
those dealing with HTTP/1.1 will simply process one request at a time
and wait for the handshake if needed (that's what we do in haproxy BTW).

Willy

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 29 Nov 2017 08:52:23 -0600

> https://github.com/httpwg/http-extensions/pull/440

I read it; thanks.

> instead agree that pipelining isn't important enough to waste text on.

SGTM

> start sending again as though the connection was new. "

This one I'm less enthusiastic about reviewing.  In the alternate
universe where I had written "this" document, I planned to explicitly
mention the connection preface for this case.  That said, your proposal
is not wrong, it just seems like a question of emphasis and how much we
want to rely on something being "obvious" for all readers, and whether
basic interop testing at implementation time will force the correct
interpretation.

> summary and is included elsewhere.

Okay.

> relative merits of enabling early data if origin servers don't support

I like the reword in the PR.

Thanks!

-Ben

---

From: Victor Vasiliev <[email-masked]>
Date: Wed, 29 Nov 2017 11:24:06 -0500

Hi everyone,

Glad to see this draft reaching WGLC so quickly!  I am looking forward to
implementing the Early-Data/425 Too Early mechanism.

I've already reviewed this draft in the past, and it has not changed much
conceptually, so this is mostly editorial nits.

"early data is concatenated with other application to form a single stream"
--
do you mean "other *application* data"?

"If HTTP/2 is selected after early data is rejected, a client sends another
connection preface" -- this feels somewhat redundant given what's already
said
in the paragraph.

"A gateway that is uncertain about whether an origin server supports the
Early-Data header field SHOULD disable early data." -- this sounds weird. Is
there an implicit assumption that the gateway only serves a single origin?

"Implementations MUST either ensure that any early data that is delivered
late
is either discarded or consistently identified and processed." -- I am not
quite sure what exactly this means.  Is that (re)statement of the
requirement
that the early data status is not changed in the middle of processing?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 30 Nov 2017 13:26:08 +0000

Hi Martin,

(Sorry for the slow response, was on a few days off)

> https://github.com/httpwg/http-extensions/pull/429

Both of those look better to me, thanks,

S.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 1 Dec 2017 11:19:17 +1100

Hi Victor,

I think that most of your comments were addressed in response to other
reviews, but there is one thing no one else picked up on:

> that the early data status is not changed in the middle of processing?

Late delivery of early data could lead to a server (or intermediary
acting as one) processing that data in a fashion that is inconsistent
with other server instances.  While it's true that the data wasn't
replayed toward *this* server instance, that doesn't mean that it
wasn't replayed toward another instance.  It's important to treat that
data properly.

FWIW, ekr and I discussed what to do with this in NSS, and while it's
suboptimal, we took the cheap option: we discard early data that
arrives after the handshake completes.

I've clarified this some, I hope:
https://github.com/httpwg/http-extensions/pull/442