Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt

Martin Rex <mrex@sap.com> Wed, 02 June 2010 15:19 UTC

Return-Path: <mrex@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 359653A6874 for <tls@core3.amsl.com>; Wed, 2 Jun 2010 08:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level:
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[AWL=0.210, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 WVxprflruwHq for <tls@core3.amsl.com>; Wed, 2 Jun 2010 08:19:55 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 112B03A6807 for <tls@ietf.org>; Wed, 2 Jun 2010 08:19:54 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o52FJWE2025516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 2 Jun 2010 17:19:32 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201006021519.o52FJVio005412@fs4113.wdf.sap.corp>
To: bmoeller@acm.org (Bodo Moeller)
Date: Wed, 2 Jun 2010 17:19:31 +0200 (MEST)
In-Reply-To: <2728902C-B235-4AAB-8EAE-19D673A38CB6@acm.org> from "Bodo Moeller" at Jun 2, 10 10:15:33 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: tls@ietf.org, nagendra@cs.stanford.edu
Subject: Re: [TLS] Fwd: I-D Action:draft-bmoeller-tls-falsestart-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@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, 02 Jun 2010 15:19:56 -0000

Bodo Moeller wrote:
> 
> > 	Title           : Transport Layer Security (TLS) False Start
> > 	Author(s)       : A. Langley, et al.
> > 	Filename        : draft-bmoeller-tls-falsestart-00.txt
> > 	Pages           : 11
> > 	Date            : 2010-06-02

I think that security considerations should spend some words on
the authentication performed by the client.  The last words of
section 1 of rfc-5246:

   The decisions on [...] how to interpret the authentication certificates
   exchanged are left to the judgment of the designers and implementors
   of protocols that run on top of TLS.

In an abstract fashion, an app client ought to always perform the "server
endpoint identification" before sending any application data to the
server.  But in the rfc-5246 architecture, this app decision is based
on a fully verified handshake.

TLS False Start change the architecture, in that it requires the
app client to perform an "optimistic server endpoint identification"
based on unverified information from an incomplete TLS handshake.

In those application architectures, where the client app authentication
is _not_ performed through a callback, but instead in a synchronous
fashion after completion of the TLS handshake, TLS False Start will
likely not be possible.

And I think that a client should _not_ try TLS False Start with
a Server that lacks TLS Renegotiation Extension support (rfc5746).


-Martin