Re: [TLS] One stream to rule them all (was Re: Security review of TLS1.3 0-RTT)

[Martin Thomson <[e-mail]>]

On 4 May 2017 at 11:41, Benjamin Kaduk <[e-mail]> wrote:
> A related question is whether NSS wants to be a general-purpose TLS library,
> or an HTTP-specific TLS library.  I have mostly come to terms with the HTTP
> application profile for 0-RTT saying "combine the streams" (but still want
> to see it written down with a proper security analysis before it gets
> widespread), but other application profiles might do different things!  Are
> you painting yourself into a corner?

Sure, in a multi-dimensional space, corners can appear in the
strangest places.  But given that TLS is streams on both sides, I
can't think of a way that an alternative model would make sense.  It's
definitely the case that an application protocol could be designed to
deal with 0-RTT as a separate stream, but when all they wanted was a
stream abstraction, the idea that there might be an antechamber stream
they have to deal with separately is hard to reason about.

It's harder still when you consider data limits on 0-RTT and the need
to complete the handshake in a timely fashion.  A separate thing could
mean that sending 0-RTT would block handshake completion because the
sender might want to ensure that a complete "thing" was sent in 0-RTT.
Either that or you have to deal with truncation.

If we need another API, it's not impossible to build one, with options
to cause 0-RTT to be routed to it.  I just don't see us needing one
any time soon.