Re: [TLS] Add max_early_data_size to TicketEarlyDataInfo

Merged

On Sat, Oct 8, 2016 at 4:00 PM, Eric Rescorla <ekr@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 <davidben@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 <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
>>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>