On 4 May 2017 at 11:41, Benjamin Kaduk <[email protected]> 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. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
