On 24 June 2016 at 00:26, Watson Ladd <watsonbl...@gmail.com> wrote: > 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.
That's a very different constraint on the usage. In one, you have to identify data as being "for 0-RTT" very explicitly. In the other, you have to have all the data available when you send a ClientHello. The latter is rarely the case. > 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? I don't think that's what I'm suggesting. I don't intend to change the signals in the current draft, namely that the handshake indicates the presence (ClientHello) and acceptance (ServerHello) of 0-RTT. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
