Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

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 <bkaduk@akamai.com> wrote:

On 10/07/2016 11:57 AM, Filippo Valsorda wrote:

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

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

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

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.

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

-Ben

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

[Please keep me in the CC of replies]

_______________________________________________
TLS mailing listTLS@ietf.orghttps://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls