Re: [TLS] New "Fast-Track" draft posted

[Martin Rex <Martin.Rex at sap.com>]

Nagendra Modadugu wrote:
> 
> I'm joining the discussion a little bit late.  Is there still time to
> consider 1-RTT version of the full-handshake described in "Fast-Track"
> paper? (i.e. client sends the ClientKeyExchange message speculatively before
> receiving the ServerHello).

To me, this looks more like a flawed assumption rather than a
"speculative action", because it is impossible to recover.

The idea behind the short cuts is that the server can continue
with the full handshake if the shortcut is not available for
whatever reason.  Sending a ClientKeyExchange based on
assumptions what the contents of the ServerHello will be
precludes the Server from making decisions to which it is
entiteled in the original TLS protocol, and the result can
easily be a fatal error, which means that the network communication
channel must be closed and reopened -- a recovery at the
TLS protocol level is impossible.


Having the Client send (protected) application data optimistically
following the Client Finished message without waiting for the
Server Finished seems like an acceptable optimization
if you badly need to cut down the number of round trips.

Such an optimization, however, may have a significant impact
on the semantics of SSL_connect for APIs like that of OpenSSL.

-Martin