Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

Merged On Sat, Oct 8, 2016 at 4:00 PM, Eric Rescorla 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 > wrote: > >> We were also expecting to want to

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

2016-10-07 22:06 GMT+ David Benjamin : > 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.

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

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 wrote: > We were also expecting to want to bound how much traffic a server could be > compelled to skip over without making progress. It

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

Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

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