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

[Ilari Liusvaara <[e-mail]>]

On Mon, May 08, 2017 at 09:33:27PM -0500, Benjamin Kaduk wrote:
> 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:
> >
> > - 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.

Also, any device that has access to semi-accurate time (relative time
in protocols has other benefits, like not having increase magnitude with
time) could do first-order compensation, which already renders the clocks
pretty accurate, even if time comparision occurs relatively rarely.

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

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.


-Ilari