Re: [TLS] 0-RTT, server Application Data, and client Finished

On Tue, Jan 26, 2016 at 8:28 PM Martin Thomson <martin.thomson@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 <davidben@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
> >
>