Re: [TLS] The case for a single stream of data

[Benjamin Kaduk <[e-mail]>]

On 05/08/2017 11:45 PM, Ilari Liusvaara wrote:
> On Mon, May 08, 2017 at 09:33:27PM -0500, Benjamin Kaduk wrote:
>> On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:
>>
>>> - That automatic wait on 0-RTT failure seems just the kind of feature
>>>   that gets disabled. Furthermore, 10 second idle on connection is
>>>   going to trigger quite a bit of connection timeouts.
>> I could believe that people would accept buffering data until the 1-RTT
>> handshake finishes (combined with rate limiting on the number of
>> connections with accepted 0-RTT data); I don't think people would accept
>> "wait the full clock skew allowance", though.
> Did I misread the thread-starter proposal for waiting the allowance?

No, I think you read it correctly (and I agree with you).
I have a more detailed reply to the original message in a compose
window, but it will not be done tonight.

> I think the early data provisioning already has 0-RTT buffer size, for
> the case the server buffers the 0-RTT data (this buffering obviously
> destroys the utility, but if it doesn't occur on every connection...)
>
>>> - There seems to be no consideration how this interacts with 0-RTT
>>>   exporters (probably applications that accept 0-RTT will then use
>>>   0-RTT exporters for the entiere connection, and those exporters have
>>>   seriously weaker properties).
>>>
>> Yeah, the 0-RTT exporter feels like a footgun waiting to be used.
> Unfortunately, looks like some are planning to use it, in ways
> seriously broken unless the server does full replay-caching.
>

:( :( :(

Clearly we should make sure their documents prominently note the
requirement for strong replay protection, but is there more we can do?

-Ben