Re: [TLS] Justification

Marsh Ray <marsh@extendedsubset.com> Wed, 12 May 2010 17:24 UTC

Return-Path: <marsh@extendedsubset.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 B082E3A6DB3 for <tls@core3.amsl.com>; Wed, 12 May 2010 10:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.58
X-Spam-Level:
X-Spam-Status: No, score=-0.58 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_40=-0.185]
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 AJAvsJD-p2p6 for <tls@core3.amsl.com>; Wed, 12 May 2010 10:24:46 -0700 (PDT)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id B3C273A6CF1 for <tls@ietf.org>; Wed, 12 May 2010 09:59:51 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OCFHZ-000HuQ-7K; Wed, 12 May 2010 16:59:41 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id BED24631D; Wed, 12 May 2010 16:59:36 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+e1+SZySmiMZEcF7tc9sOZxHmMykdxt6Q=
Message-ID: <4BEADE7A.2070002@extendedsubset.com>
Date: Wed, 12 May 2010 11:59:38 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: Simon Josefsson <simon@josefsson.org>
References: <20100510221531.GC9429@oracle.com> <201005111339.o4BDdoYQ009725@fs4113.wdf.sap.corp> <20100511152153.GF9429@oracle.com> <201005111803.o4BI3fhO006065@stingray.missi.ncsc.mil> <20100511190958.GR9429@oracle.com> <4BE9B0BC.2000101@extendedsubset.com> <20100511194620.GU9429@oracle.com> <4BE9B856.40000@extendedsubset.com> <20100511200728.GW9429@oracle.com> <4BE9CC88.6040103@extendedsubset.com> <87aas5sbzy.fsf@mocca.josefsson.org> <4BEAC145.60607@pobox.com> <1273676748.1486.4.camel@sockerbit>
In-Reply-To: <1273676748.1486.4.camel@sockerbit>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "Kemp, David P." <DPKemp@missi.ncsc.mil>, tls@ietf.org
Subject: Re: [TLS] Justification
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, 12 May 2010 17:24:48 -0000

On 5/12/2010 10:05 AM, Simon Josefsson wrote:
> ons 2010-05-12 klockan 07:55 -0700 skrev Michael D'Errico:
>> Can someone please remind me why we want cached-info?

It saves KB++ at the beginning of handshakes, which is a really big deal
for some deployments.

>> It seems that
>> the problems it creates aren't worth the small optimization it might
>> provide.
> 
> I still have hope we can rescue the extension.

Me too. It may be as simple as agreeing on the right hash function (or
the minimally functional subset of the extensible set containing all
negotiable choices).

> The use-case I have seen
> is that server cert chains and list of trusted CAs can easily make a TLS
> 30-40kb large.  Caching would reduce this.
> 
> However, TLS session resume also solves this problem, and it is
> relatively easy to implement in most libraries.

The important thing that this _could_ enable, which resumption does not,
is the ability to persist the cached info onto
less-than-perfectly-trusted media. I.e., save it as /tmp files and if
the hard drive is sold on ebay it doesn't represent a disclosure.

Come to think of it, that may be the best argument of all in favor of a
strong hash function: it enables the cache to be kept for arbitrary
lengths of time without special protections or serious security
considerations.

- Marsh