On Mon, Dec 12, 2016 at 5:54 PM, David Benjamin <david...@chromium.org> wrote:
> 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). > FWIW, this is how NSS behaves. -Ekr > > 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 > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
