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

[Benjamin Kaduk <[e-mail]>]

On 05/06/2017 04:58 AM, Ilari Liusvaara wrote:
> On Fri, May 05, 2017 at 09:28:07AM -0700, Colm MacCárthaigh wrote:
>> I wanted to start a separate thread on this, just to make some small
>> aspects of replay mitigating clear, because I'd like to make a case for TLS
>> providing a single-stream, which is what people seem to be doing anyway.
> <Snip a long mail>
>
> Couple points:
>
> - AFAIK, the 10 second or so figure in existing spec is a slop margin,
>   which means the replay window would be 20 seconds, not 10.

As the author of that text, I mostly intended it to be the total window,
not the slop margin.  But the main idea was to give an order of
magnitude, i.e., "shorter than minutes".

> - The size of the window depends on clock error margin and transport
>   delay margin. At 1s/day clock error margin, you need 14 second
>   window just from clock error.

Or you can accept full handshakes every couple hours.  Amortized that
may not be bad, if you have lots of connections.  Or you may only have
one connection every day ever, in which case it is noticeable.  It's
pretty situation-dependent.

> - It is not just low-power devices with really bad clocks. I have seen
>   20s per day(!) clock drift on high-power device that doesn't sleep.

Is there a problem with saying that devices with bad clocks talking to
beefy web servers don't get to do 0-RTT?  I don't see a problem with it.

> - So basically, the size of window is tradeoff with number of devices.

Yes.

> - 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.

> - 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.

-Ben