Merged On Sat, Oct 8, 2016 at 4:00 PM, Eric Rescorla <e...@rtfm.com> wrote:
> 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 <david...@chromium.org> > wrote: > >> 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 >> >> >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
