Subject: [TLS] Add max_early_data_size to TicketEarlyDataInfo

From: Filippo Valsorda <[email-masked]>
Date: Fri, 07 Oct 2016 12:57:37 -0400

Hello,

Cloudflare's current (not definitive) plan for 0-RTT is essentially to
decide whether or not to answer to requests in the 0.5 flight on a
case-by-case basis. That obviously requires reading all of them and
caching the ones we don't want to answer.

To mitigate the obvious DoS concern we plan to use the ticket age and a
per-machine replay cache.

However, chatting with Drew (cc'd) we realized that clients could still
send huge amounts of 0-RTT data that we would have to buffer. Once a
client sent early data, there's no way to accept only a part of it or to
verify that the client is not replaying before reading it all. But if we
were to close the connection after a given amount of data we risk
failing connections from legal clients.

I propose to add a field max_early_data_size to TicketEarlyDataInfo, to
inform clients about the maximum amount of 0-RTT data they are allowed
to send, allowing servers to safely terminate connections that exceed
it.

https://github.com/tlswg/tls13-spec/pull/674

[Please keep me in the CC of replies]

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 7 Oct 2016 16:45:30 -0500

> send huge amounts of 0-RTT data that we would have to buffer. Once a

Well, "have to" is perhaps a bit of a stretch; the client should be
prepared to cope reasonably if you abort the connection arbitrarily.

> to send, allowing servers to safely terminate connections that exceed

But this seems like a good idea; I left a couple of ~editorial notes on
github.

-Ben

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: David Benjamin <[email-masked]>
Date: Fri, 07 Oct 2016 22:06:35 +0000

We were also expecting to want to bound how much traffic a server could be
compelled to skip over without making progress. It actually didn't occur to
me we could let the client know the bounds, rather than just making up a
conservative bound (there's only so much data you can get into an RTT) and
hoping nothing breaks. That's a good idea.

Units is a little interesting. For those purposes, this limit would kick in
whether or not the early data could be decrypted, so the server-side limit
would be measured in ciphertext, possibly even including record headers.
(Although any inaccuracies in converting could be done by just advertising
an underestimate and breaking peers that send pathologically silly things
like all one-byte records. So it doesn't matter much.)

On Fri, Oct 7, 2016 at 5:45 PM Benjamin Kaduk <[email-masked]> wrote:

Hello,

I think the concern is that a well-meaning client may not necessarily do a
retry here and instead read this even as a network error. And if it did,
the next attempt, if there is still a 0-RTT-able ticket available, may hit
this again anyway...

-Ben

_______________________________________________
TLS mailing [email-masked]://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 8 Oct 2016 16:00:39 -0700

I agree that this is a good idea. Absent objection, i'm going to merge this
PR on Monday

On Fri, Oct 7, 2016 at 3:06 PM, David Benjamin <[email-masked]>
wrote:

> Units is a little interesting. For those purposes, this limit would kick
> in whether or not the early data could be decrypted, so the server-side
> limit would be measured in ciphertext, possibly even including record
> headers. (Although any inaccuracies in converting could be done by just
> advertising an underestimate and breaking peers that send pathologically
> silly things like all one-byte records. So it doesn't matter much.)
>

---

From: Filippo Valsorda <[email-masked]>
Date: Mon, 10 Oct 2016 20:22:31 +0100

2016-10-07 22:06 GMT+0000 David Benjamin <[email-masked]>:
> Units is a little interesting. For those purposes, this limit would
> kick in whether or not the early data could be decrypted, so the server-
> side limit would be measured in ciphertext, possibly even including
> record headers. (Although any inaccuracies in converting could be done
> by just advertising an underestimate and breaking peers that send
> pathologically silly things like all one-byte records. So it doesn't
> matter much.)

Yeah, I've been thinking about that. I went for plaintext because it
seemed to simplify the API on the client side, but maybe it's best to
count  the whole record size, and let the client worry about not doing
some silly splitting or padding.

I'll update the PR.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 Oct 2016 13:51:33 -0700

Merged

On Sat, Oct 8, 2016 at 4:00 PM, Eric Rescorla <[email-masked]> wrote:

> I agree that this is a good idea. Absent objection, i'm going to merge
> this PR on Monday
>
>> We were also expecting to want to bound how much traffic a server could
>> be compelled to skip over without making progress. It actually didn't occur
>> to me we could let the client know the bounds, rather than just making up a
>> I think the concern is that a well-meaning client may not necessarily do
>> a retry here and instead read this even as a network error. And if it did,