On Mon, Dec 12, 2016 at 8:45 PM Martin Thomson <martin.thom...@gmail.com> wrote:
> On 13 December 2016 at 12:43, Nick Harper <nhar...@google.com> wrote: > > Right now, I believe it's legal for a client to send ClientHello, early > > data, and end_of_early_data alert without reading any messages from the > > server. This change would require a client to wait for the ServerHello > > before sending (or not) EndOfEarlyData, but that seems quite reasonable. > > It's legal to send EndOfEarlyData at any time as long as it follows > the (first) ClientHello, but you are right in observing that it would > be difficult to send it at a different time than when you are entering > it into the transcript. > > p.s., It's the Server Finished that you have to wait for, not just > ServerHello. > I think sending EndOfEarlyData/end_of_early_data late is desirable anyway, even if you know you won't be sending more 0-RTT data. That forces servers to get the processing order right: https://tlswg.github.io/tls13-spec/#rfc.section.4.2.8.1 If by including it in the transcript, we make it more likely that clients will send in a way that forces correct server behavior, that sounds like a good thing for the ecosystem. It also shouldn't be any more complexity for the client to send it later because the client must already have logic to change keys and send a Finished message after receiving ServerHello..Finished. The EndOfEarlyData just tacks before that (as I expect most clients would have implemented the alert version anyway). To add to the motivations: EKR mentioned end_of_early_data is the only place where we transition keys on an alert. Conversely, it's also the only alert that does not terminate the connection. (The document even currently claims end_of_early_data is a "closure alert" and signals "that the connection is ending". This is false.) David
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
