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

Adam Langley <agl@google.com> Wed, 02 June 2010 19:11 UTC

Return-Path: <agl@google.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 B5A4A3A6A07 for <tls@core3.amsl.com>; Wed, 2 Jun 2010 12:11:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.377
X-Spam-Level:
X-Spam-Status: No, score=-103.377 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ToYizyrFMjeA for <tls@core3.amsl.com>; Wed, 2 Jun 2010 12:11:39 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 506483A68AD for <tls@ietf.org>; Wed, 2 Jun 2010 12:11:39 -0700 (PDT)
Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id o52JBKgQ009826 for <tls@ietf.org>; Wed, 2 Jun 2010 12:11:24 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1275505884; bh=aVUA8nv35ccjvFp9fGr2321W0J8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=w9sPqzvwYK/6cgmR1DjpQBJ/g4b50WgpV3Z5dNsYNGS+DfbBA2Ik10kJcGlWe86Iz 60/NUbSj7QmaTMt8wJlCA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:x-system-of-record; b=k9Xlwvy2UaZOeh2SmfMA8OA7AoNazqqVLNOQaTDz4QKzfkCXTzDl6rRw9avXs2ShK TmdxBszoKct97uUqA30NQ==
Received: from gwj15 (gwj15.prod.google.com [10.200.10.15]) by wpaz5.hot.corp.google.com with ESMTP id o52JBJWD007441 for <tls@ietf.org>; Wed, 2 Jun 2010 12:11:20 -0700
Received: by gwj15 with SMTP id 15so1107655gwj.24 for <tls@ietf.org>; Wed, 02 Jun 2010 12:11:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.59.9 with SMTP id j9mr4071353ibh.31.1275505879677; Wed, 02 Jun 2010 12:11:19 -0700 (PDT)
Received: by 10.231.129.137 with HTTP; Wed, 2 Jun 2010 12:11:19 -0700 (PDT)
In-Reply-To: <4C06A923.7010901@extendedsubset.com>
References: <2728902C-B235-4AAB-8EAE-19D673A38CB6@acm.org> <201006021519.o52FJVio005412@fs4113.wdf.sap.corp> <AANLkTinHnMzCSv7qK9ZhiC6SXVEOU2L-52LQJLTnEDvL@mail.gmail.com> <4C06A923.7010901@extendedsubset.com>
Date: Wed, 2 Jun 2010 15:11:19 -0400
Message-ID: <AANLkTikryra8LdH-E5R-psQ5MYBPSx4fK3XuO4k1ucpw@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Marsh Ray <marsh@extendedsubset.com>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: tls@ietf.org
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
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 19:11:42 -0000

On Wed, Jun 2, 2010 at 2:55 PM, Marsh Ray <marsh@extendedsubset.com> wrote:
> 1. This proposal scares me. Wasn't the Finished message added in
> response to vulnerabilities in SSLv2? Doesn't this sort of, umm, undo
> that for initial data from the client? It bears repeating that in TLS
> usage for a secure web application that first transmission from the
> client to the server would be expected to contain the session cookie,
> perhaps even the full plaintext credentials for a form-based login. The
> entire security model of web apps is based on the inability of the
> attacker to decrypt this.

Agreed that the first request from the client to the server is very
sensitive. If someone finds a way to decrypt this because of False
Start then that's a fatal flaw.

> 2. Couldn't a similar optimization be achieved without protocol changes
> by simply implementing session resumption more robustly? Session
> resumption also takes things like cert chain validation and revocation
> checking out of the critical path of the handshake but this proposal
> still depends on it.

Can you expand on 'robustly'? We cannot store session information on
disk which limits its applicability. Although we'll always try
resumption when we can.

It's true that cert chain revocation is still in play here. OCSP
multi-stapling will hopefully address that.

> Last I checked this included IE, Chrome, and everyone else that used
> Schannel on MS Windows.

Chrome no longer uses SChannel on Windows in the latest development
channel builds (and False Start is enabled in these development
releases).

> But the server's Finished message will not have been validated by the
> client, so the security analysis for the RI fix must start over with the
> expectation that the client cannot trust the presence or absence of an
> RI extension. If the client didn't ever have to trust it, then why did
> we send it in the server-to-client direction anyway?
>
> AFAICT, RI is the only TLS extension that's presence is mandatory for
> security purposes. But other extensions affect the handshake somehow or
> else they wouldn't be sent, and how much of TLS really doesn't affect
> security somehow? E.g. SNI? Seems like everything must be re-analyzed
> from scratch if we are to be safe sending confidential data before fully
> validating the server.

I agree that careful thought is required for this change. At this
point several people have considered it and not found any issues save
for the ones enumerated in the draft.



Cheers

AGL