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

From: Stefan Santesson <[email-masked]>
Date: Mon, 04 May 2009 12:27:59 +0200

Generally I would like to avoid things that prevents this from being as
simple as possible.

Reading Martin's reply I don't feel this would be a suitable amendment.

/Stefan

On 09-04-29 3:14 AM, "Martin Rex" <[email-masked]> wrote:

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