Re: [TLS] Cached-info substitution

Adam Langley <agl@google.com> Fri, 19 February 2010 16:26 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 35FB928C262 for <tls@core3.amsl.com>; Fri, 19 Feb 2010 08:26:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.977
X-Spam-Level:
X-Spam-Status: No, score=-104.977 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, 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 26aYHfLpFdw7 for <tls@core3.amsl.com>; Fri, 19 Feb 2010 08:26:15 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 290EC28C14E for <tls@ietf.org>; Fri, 19 Feb 2010 08:26:15 -0800 (PST)
Received: from wpaz13.hot.corp.google.com (wpaz13.hot.corp.google.com [172.24.198.77]) by smtp-out.google.com with ESMTP id o1JGS0r1022355 for <tls@ietf.org>; Fri, 19 Feb 2010 16:28:00 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1266596881; bh=uncf8zWbXRJTAA7m5Slo51aCOl8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qQAD+xHo9LK0/H+WvprHBXyAjOJIIv0CuXmJHJTqyiXSbinUXIihuJIbR1SJGQ5bK VlgsbZMejLxd3Lb4KpeoA==
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=hg8dFuBskLDO//6BqhJgJNrlGxyAS1uB0N4yzqIZA85f05RQhNlUNAyksQ61e/ZwI Vw2+uz3M050nO74SPYlyQ==
Received: from pxi36 (pxi36.prod.google.com [10.243.27.36]) by wpaz13.hot.corp.google.com with ESMTP id o1JGRwow013988 for <tls@ietf.org>; Fri, 19 Feb 2010 08:27:59 -0800
Received: by pxi36 with SMTP id 36so114870pxi.20 for <tls@ietf.org>; Fri, 19 Feb 2010 08:27:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.142.118.5 with SMTP id q5mr7538031wfc.320.1266596878472; Fri, 19 Feb 2010 08:27:58 -0800 (PST)
In-Reply-To: <C7A4666D.8663%stefan@aaa-sec.com>
References: <4B7D8AAD.80204@briansmith.org> <C7A4666D.8663%stefan@aaa-sec.com>
Date: Fri, 19 Feb 2010 11:27:58 -0500
Message-ID: <a84d7bc61002190827t66450279vf3861d7e34425f04@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Stefan Santesson <stefan@aaa-sec.com>
Content-Type: text/plain; charset=UTF-8
X-System-Of-Record: true
Cc: tls@ietf.org
Subject: Re: [TLS] Cached-info substitution
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: Fri, 19 Feb 2010 16:26:16 -0000

On Fri, Feb 19, 2010 at 10:01 AM, Stefan Santesson <stefan@aaa-sec.com>; wrote:
> 1) To define a format for the handshake message which include the hash
> substitution using a syntax that alters the defined syntax of the handshake
> message. (current draft approach)
>
> 2) To define a format which preserves the original handshake message syntax.

I'm afraid that I'm still not clear what you mean here.

In the current draft:

"Following a successful exchange of "cached_information" extensions,
the server may replace data objects identified through the client
extension with any of the CachedInformationHash values received from
the client, which matches the replaced object."

My understanding is that this is a "memcmp for magic values" scheme.
Given the size of the hashes, this isn't unreasonable, I just feel
that we should be more explicit if possible.

Given that, we could

1) define new handshake messages, although you're correct that the
namespace is small.

2) Redefine the structure of the existing handshake messages for the
case when this extension is in effect. The new structures would have
an explicit field for substituted hashes, in addition to the old
fields. Hosts would choice one or the other to be non-zero length.
(Based on my knowledge of NSS and OpenSSL's code, this wouldn't be too
bad to implement.)

3) Wedge the cached values into the current structures somehow. Brian
suggests using zero lengths as a magic marker. However, the hash value
would still need to follow because the client could have predicted one
of several values. I think this is a poor man's version of option two.


AGL