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. _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
