[TLS] Possible alternative to current cached info draft

Michael D'Errico <mike-list@pobox.com> Mon, 17 May 2010 19:21 UTC

Return-Path: <mike-list@pobox.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 CBB9828C123 for <tls@core3.amsl.com>; Mon, 17 May 2010 12:21:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.72
X-Spam-Level:
X-Spam-Status: No, score=-0.72 tagged_above=-999 required=5 tests=[AWL=-0.721, BAYES_50=0.001]
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 p7HnYbOSCAGG for <tls@core3.amsl.com>; Mon, 17 May 2010 12:21:55 -0700 (PDT)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 101FF28C0F6 for <tls@ietf.org>; Mon, 17 May 2010 12:21:18 -0700 (PDT)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id E10BAB465C; Mon, 17 May 2010 15:21:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=eTeU5SR4bUIf Ct/bivkh9nhNC2Q=; b=W1WYhjLpl/cIqanYiE0MpuZNTtKKJXkE5O5BcdSIuqUS 1eaVkGmhvtYKnMTcZaF2j18gmA4hzBFVkjnwEuqSdVXnnNUShOE6oxWtljTf8SF1 et68gsvxOB5CU2ZuZ/I9YSd9Iqu34G54lVjKkTo3N05cDdBNSL+r180fiaXXdFc=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=tLxoeE 0zN5P1RDIcnqxvH7newjssPPkHfmWIYqcnoMonVyTnYV+ZakcNofRv5j00g4kFnk af5Q60vLEzuvOJqA9KtjHJce2V/5iDeKXHlF8YU0QfL+pGerXEo63DaUb7wxSbZx nbkuweDpEkuoT6dkMmhxtiGayzDusgkBuaiO0=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id BA152B4659; Mon, 17 May 2010 15:21:08 -0400 (EDT)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 115AEB4654; Mon, 17 May 2010 15:21:06 -0400 (EDT)
Message-ID: <4BF19721.8050005@pobox.com>
Date: Mon, 17 May 2010 12:21:05 -0700
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
References: <C8171810.ADE4%stefan@aaa-sec.com>
In-Reply-To: <C8171810.ADE4%stefan@aaa-sec.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 58AB686C-61E9-11DF-8ECF-D033EE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Cc: tls@ietf.org
Subject: [TLS] Possible alternative to current cached info draft
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: Mon, 17 May 2010 19:21:56 -0000

It just hit me that we might be able to do caching in a different
way, similar to the http If-Modified-Since header (and ETag -- see
the last paragraph).

The server would keep track of the time at which its certificate
chain (or CA list) was configured.  This could be determined by
looking at the modification time in the filesystem, or even just
by keeping track of when the server was started or was told to
reconfigure itself.

A connecting client would tell the server, "I have a certificate
chain with this timestamp," and the server would either respond
saying that the timestamp matches the current chain, or not.  If
it matched, the certificate message sent by the server would be
empty.

A client that has never connected to a server would request the
server's timestamps by sending an empty extension.  The server
would respond with the current type/timestamp pairs it supports.

When reconnecting, the client lists its type/timestamp pairs and
the server responds with its list.  Any timestamps that matched
would cause the server to omit the data.

But probably we'd also need to have id's for the objects similar
to the ETag header to disambiguate things, especially when the
server handles more than one virtual domain.  The server could
generate those either using a hash (no agility needed) or some
other way, with the only requirement being that the type-id-
timestamp triple would need to be unique.

Mike



Stefan Santesson wrote:
> I would like to wrap up the discussion about cached info, if possible.
> 
> I have to admit that I'm stuck as editor. I have a draft that I think is
> done with a possible amendment to the security considerations and some
> additional informational references to FNV.
> 
> I don't think the discussion has shown that the security assumptions are
> wrong, I.e. That any alteration of cached data in the sense that the server
> and the client are in disagreement of what the cached data is, will lead to
> a handshake failure.
> 
> Threats are therefore reduced to inconveniences upon handshake failures (as
> far as discussion has showed.
> 
> However, there is still a possible alteration of the security properties of
> the finished calculation. That is, it is possible upon a FNV collision to
> disagree on the cached data without failing the finished calculation.
> 
> I can't see any practical exploit of this fact. If this is considered a
> blocking problem, then it is easiest solved by using a secure hash (SHA-256)
> which effectively restores the security properties of the finished
> calculation. This is best done by s/FNV/SHA-256. No agility.
> 
> I will not lead an effort to specify a variant of this protocol where the
> server provides the identifiers, either as any random identifier or in the
> form of a URI. If that is the desire of the WG, I will be happy to hand over
> editorship to anyone, assigned by the chairs, who wants to take over.
> 
> I request WG chair guidance on how to proceed, if at all with this document.
> 
> /Stefan