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

Martin Rex <Martin.Rex@sap.com> Wed, 29 April 2009 01:17 UTC

Return-Path: <Martin.Rex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CFEB3A68EC for <tls@core3.amsl.com>; Tue, 28 Apr 2009 18:17:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.753
X-Spam-Level:
X-Spam-Status: No, score=-5.753 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtRblLhe+j7E for <tls@core3.amsl.com>; Tue, 28 Apr 2009 18:17:05 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 0F5653A6811 for <TLS@ietf.org>; Tue, 28 Apr 2009 18:17:04 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id n3T1EJYG011325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Apr 2009 03:14:19 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200904290114.n3T1EI4h003479@fs4113.wdf.sap.corp>
To: ngm+ietf@google.com
Date: Wed, 29 Apr 2009 03:14:18 +0200
In-Reply-To: <28425e380904281725g75407fcj823bf9e7d83421b3@mail.gmail.com> from "Nagendra Modadugu" at Apr 28, 9 05:25:20 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: stefans@exmsft.com, TLS@ietf.org
Subject: Re: [TLS] New "Fast-Track" draft posted
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: martin.rex@sap.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2009 01:17:06 -0000

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