On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson <martin.thom...@gmail.com> wrote: > On 22 June 2016 at 12:01, Watson Ladd <watsonbl...@gmail.com> wrote: >> Why isn't 0-RTT an extension in the Client Hello to deal with this? > > You can't stream extensions, which unfortunately is required given how > most software interacts with their TLS stack.
A few months ago we had a lengthy discussion on the list and at TRON about how risky 0-RTT is. This culminated in the idea that 0RTT data should be provided through a distinct channel to the application, along with feedback about whether it was not accepted. If we're willing to change the interaction pattern to support that, we can accommodate using 0RTT as an extension by gathering it all and sending when the handshake happens. But it sounds like you are discussing a design where the handshake fakes completion if 0-RTT is on, and at some point later "well, i didn't actually send the data you wanted to". Or am I missing something about the API design that is motivating this streaming approach? > > Let's be clear, the actual risk we're talking about is pretty-much > confined to screw-ups. The deployment screwup where you left one > server speaking TLS 1.2 somewhere before turning 0-RTT on; and TLS > MitM, which calling a screw-up might be too positive a statement. Or you turned on 0-RTT and then got a security advisory resulting in rolling back to TLS 1.2. > > Of course, David is right that screw-ups like this are too common for > us to do nothing about them. -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
