Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted

Adam Langley <agl@google.com> Tue, 02 February 2010 15:40 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 951543A6B1E for <tls@core3.amsl.com>; Tue, 2 Feb 2010 07:40:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.977
X-Spam-Level:
X-Spam-Status: No, score=-101.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Qy8H7bkHgDYl for <tls@core3.amsl.com>; Tue, 2 Feb 2010 07:40:36 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 67E2E3A6B19 for <tls@ietf.org>; Tue, 2 Feb 2010 07:40:34 -0800 (PST)
Received: from kpbe14.cbf.corp.google.com (kpbe14.cbf.corp.google.com [172.25.105.78]) by smtp-out.google.com with ESMTP id o12FfBT8022971 for <tls@ietf.org>; Tue, 2 Feb 2010 07:41:12 -0800
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265125272; bh=w0F02cd4bK68pA087QpU3sl/81g=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=YAC86dOw89Km+CDg+E9HFN2LWGXpNRTi+m3/yXxWZ8mzQL89BUTVSVCuLI6eoQ9J/ rTd3QtAq5XfzcShtt5NDQ==
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=tVLftp6v/qkYxNz+Nb/wyW9QgjfB/kxhrD8BKZ2f78lmbdtkhoDCjkAXrYCGS4w6u NN1ooVKkCvermcR4/hxsg==
Received: from pzk1 (pzk1.prod.google.com [10.243.19.129]) by kpbe14.cbf.corp.google.com with ESMTP id o12FdkQj014819 for <tls@ietf.org>; Tue, 2 Feb 2010 07:41:11 -0800
Received: by pzk1 with SMTP id 1so278029pzk.16 for <tls@ietf.org>; Tue, 02 Feb 2010 07:41:10 -0800 (PST)
MIME-Version: 1.0
Received: by 10.143.26.33 with SMTP id d33mr4116768wfj.38.1265125267593; Tue, 02 Feb 2010 07:41:07 -0800 (PST)
In-Reply-To: <4B684577.10603@gnutls.org>
References: <001901caa3e4$c0363750$40a2a5f0$@org> <a84d7bc61002020545n4a29f141na182b463d1de7ece@mail.gmail.com> <4B684577.10603@gnutls.org>
Date: Tue, 02 Feb 2010 10:41:07 -0500
Message-ID: <a84d7bc61002020741y5d42af6btbdf5ae0dcb97916b@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: text/plain; charset="UTF-8"
X-System-Of-Record: true
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft posted
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: Tue, 02 Feb 2010 15:40:37 -0000

On Tue, Feb 2, 2010 at 10:32 AM, Nikos Mavrogiannopoulos
<nmav@gnutls.org> wrote:
> What if I modify the server's messages, so you negotiate to a
> ciphersuite I can break, or I can derive information from (say the
> length of the plaintext data you send- as with rc4). You will not detect
> my attack until you receive the server's finished message, wouldn't you?
>
> I think this mode is walking on the edge.

Obviously, if the server can cause the client to use a NULL cipher (or
something very weak) then cut through should not be used. For Android,
cut through mode will not be used if the cipher key length is less
than 128 bits.

The length of the application data records are observable on the wire
in any case. The only advantage that an attacker could gain here is to
choose a cipher that doesn't pad records to get a slighter more
accurate length.

Given how extremely valuable saving a round trip is, we choose to make
this tradeoff.


AGL