[TLS] 0.5 RTT

[Martin Thomson <[e-mail]>]

Karthik raised some concerns here, and I think that we have some
thinking to do.  But I don't think that it is intractable, nor even
hard, to reason about this problem.

The only thing that the client's second flight provides is
authentication.  The Finished isn't needed if there is no client auth
[P].  Hugo's presentation at TRON did not include a client Finished in
the earlier, simpler examples.

Thus, based on Watson's observation that the client authentication is
removable, we might conclude that the handshake is complete from the
perspective of a server that does not require client authentication.
There are still reasons we might like to keep the client
authentication in the handshake, but those are decisions we can make
on engineering grounds.

If post-handshake client authentication is OK, then 0.5 RTT is equally
OK [X].  I would assert that any decision about changing keys after
the client Finished applies to post-handshake client auth (or vice
versa).

If that logic is sound, then I see no reason we can't have some very
simple advice:

  1. if the server does not request client authentication, it can send
application data immediately following its Finished

  2. if the server requests client authentication, it MUST NOT send
application data until it receives and validates the client's first
flight.  UNLESS the server is certain that the data it sends does not
depend on the client's identity (that is, it would send this
application data to anyone).

>From an API perspective, I believe that we should recommend that there
be a separate function for sending in condition 2, just as we are
going to recommend that there is a separate function for sending 0-RTT
data (as well as there being one to receive on the server end).

Based on this, we should recommend different points in time for the
server API to report that the handshake is "complete" at a server.  In
condition 1, the handshake is complete after the server Finished is
sent; in condition 2, the handshake is complete after the client
Finished is received.


[P] Note that a client Finished does confirm a PSK.  Though you might
reasonably argue that successfully generating valid application data
works equally well in that regard.
[X] Post-handshake client authentication has only been analyzed very
lightly, so we have to caveat that statement too.