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 <bka...@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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
