Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs

Nico Williams <nico@cryptonector.com> Wed, 28 September 2011 23:03 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE1611E8120 for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 16:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level:
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoPlyI6CAVfO for <tls@ietfa.amsl.com>; Wed, 28 Sep 2011 16:03:23 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 69FCF11E8091 for <tls@ietf.org>; Wed, 28 Sep 2011 16:03:23 -0700 (PDT)
Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 01C5059806A for <tls@ietf.org>; Wed, 28 Sep 2011 16:06:07 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=xQgpw3++kAJEzWwbDmZgyrGKPyugVa7KTX+VrA0/klDp InEKb3Umd2J3n6VnzfWXX3VT3frDd+sQre65Wr3EI4PDy6iEaM/m7hPMKns1lI+G WOMxu/JTNjS3lT4OxkW1TkjWKMO8VDNuINZgswxVhiv3CVfuWOXuAnn5E7zGqE8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=fKatTTgAg0FS2A3njBhDrpeV7h0=; b=VEK9QfQzQu8 +9v3XCvtIny6DEroQnabUUEKoa6ZH4SkYUv3O3ee/Bl9yH4iykUZCelqN+f4cq6c Wc3Z3mGLuBdQwM+QGzSpLJX3RYPGsD6rFMD3XmqPMKWcN1Q2UMXHL9WBImTCUaIH /7hpWwPIgqjTDblz4ZOAhs24lf6abRPo=
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id 83CEA598085 for <tls@ietf.org>; Wed, 28 Sep 2011 16:05:46 -0700 (PDT)
Received: by fxd18 with SMTP id 18so1234986fxd.31 for <tls@ietf.org>; Wed, 28 Sep 2011 16:05:44 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.44.103 with SMTP id d7mr21703944pbm.24.1317251143859; Wed, 28 Sep 2011 16:05:43 -0700 (PDT)
Received: by 10.68.71.138 with HTTP; Wed, 28 Sep 2011 16:05:43 -0700 (PDT)
In-Reply-To: <4E838D57.4050303@pobox.com>
References: <CAK3OfOjKwn16uKN44AjDDYoFxJwdghK=21zEKr6zSrp4gzATFQ@mail.gmail.com> <4E838D57.4050303@pobox.com>
Date: Wed, 28 Sep 2011 18:05:43 -0500
Message-ID: <CAK3OfOgdqCSTMcjuo4cb_P1akccVJgrCBMojpeutYU+ZDYSDgw@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Michael D'Errico" <mike-list@pobox.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: tls@ietf.org
Subject: Re: [TLS] Addressing cookie theft (think BEAST) with channel bound cookies using TLS session IDs
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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, 28 Sep 2011 23:03:24 -0000

On Wed, Sep 28, 2011 at 4:10 PM, Michael D'Errico <mike-list@pobox.com>; wrote:
> I haven't gone through this in detail, but one problem I see is
> that it is the client that chooses the session ID for a resumed
> session when a session ticket is used.  In fact the first (full)
> handshake doesn't even have a session ID!
>
> Of course the server can stick whatever identifiers it wants in
> the ticket (since it is opaque to the client), so this might not
> be a big deal.

At first glance this is a real problem, but in fact, it makes no sense
for the TLS server to report any session ID selected by the client --
whatever security value a TLS session ID might have had before
RFC4507, it'd have none now.

However, precisely because of this, what the server should do is
substitute, in any APIs, a server-generated session ID stored in the
ticket.  The session ID that goes on the wire is pretty much
irrelevant (though it's always possible that some application protocol
references TLS session IDs on the wire, I rather doubt this).

This would mean, possibly, changing TLS server implementations that
support RFC4507, which is less advantageous than I'd hoped for.

Nico
--