On Tue, Jan 26, 2016 at 8:28 PM Martin Thomson <martin.thom...@gmail.com> wrote:
> This is in part why I created: > https://github.com/tlswg/tls13-spec/pull/402 Ah, great. And indeed there is a paragraph I missed: """ At this point, the handshake is complete, and the client and server may exchange application layer data. Application data MUST NOT be sent prior to sending the Finished message. Note that while the server may send application data prior to receiving the client’s Authentication messages, any data sent at that point is of course being sent to an unauthenticated peer. """ In addition to the diagram, there's also some text in 6.3.4.3 which somewhat contradicts this (that's the paragraph I was going off of in writing this mail): """ [...] Once a side has sent its Finished message and received and validated the Finished message from its peer, it may begin to send and receive application data over the connection. This data will be protected under keys derived from the ephemeral secret (see Section 7). """ My understanding is that the server is able to send any data that does > not depend on client authentication at t=0.5 and any data that depends > on client authentication at either t=0.5 if it successfully consumes > the client authentication in the 0-RTT flight, or t=1.5 failing that. > This seems unnecessarily complicated and invites all the context-switching problems of mid-stream client auth in even more situations. If the server needs to send a CertificateRequest (i.e. the client mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but useless because the first authenticated byte of the response is delayed to t=1.5. We should just say that 0-RTT accept + CertificateRequest is forbidden. If one really wants to, a la mid-stream[*] auth, send unauthenticated bytes at t=0.5 and then authenticated bytes at t=1.5, one could just as easily use mid-stream auth itself. The server accepts the 0-RTT without a CertificateRequest and, at t=0.5, sends the unauthenticated bytes followed by a mid-stream CertificateRequest. At t=1, the client processes the unauthenticated bytes, sees a mid-stream CertificateRequest, authenticates, which the server receives at t=1.5, sends authenticated bytes, received by the client at t=2. The same data arrives at the same times and we don't increase the state-space. David [*] Mid-stream auth is a serious regression, and I am not endorsing it in any way. But supposing it exists for the purposes of this thread... > On 27 January 2016 at 11:46, David Benjamin <david...@chromium.org> wrote: > > It's possible I'm reading the draft wrong, so this thread may be a very > > short one. > > > > (t here is in units of RTT, so t=0 is when the client sends ClientHello > and > > t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 > is > > when the client receives ServerHello, etc.) > > > > Looking at the Zero-RTT exchange here: > > https://tlswg.github.io/tls13-spec/#rfc.section.6.2.2 > > > > Is the intention that the client, even in the successful 0-RTT case, send > > two Finished messages (one at t=0 and one at t=1) and that the server not > > send application data until receiving the second of these at t=1.5? If > so, > > does this not defeat the purpose of 0-RTT? Although the client now > eagerly > > sends at t=0, it will not see the response until t=2, which is no better > > than the resumption case (in TLS 1.2 or 1.3) where the client doesn't > send > > until t=1. > > > > 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
