Re: [TLS] New Cached info draft

Martin Rex <mrex@sap.com> Wed, 31 March 2010 19:08 UTC

Return-Path: <mrex@sap.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 6DC9B3A6A7C for <tls@core3.amsl.com>; Wed, 31 Mar 2010 12:08:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.596
X-Spam-Level:
X-Spam-Status: No, score=-8.596 tagged_above=-999 required=5 tests=[AWL=0.523, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 0K3OMyxpiIjg for <tls@core3.amsl.com>; Wed, 31 Mar 2010 12:08:22 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 5CAAD3A6A4C for <tls@ietf.org>; Wed, 31 Mar 2010 12:08:21 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o2VJ8oG4021784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Mar 2010 21:08:50 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003311908.o2VJ8nmi002947@fs4113.wdf.sap.corp>
To: agl@imperialviolet.org
Date: Wed, 31 Mar 2010 21:08:49 +0200
In-Reply-To: <o2g396556a21003311032wac904836h89b84f1a1fdeb94b@mail.gmail.com> from "Adam Langley" at Mar 31, 10 01:32:33 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] New Cached info draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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, 31 Mar 2010 19:08:23 -0000

Adam Langley wrote:
> 
> On Tue, Mar 30, 2010 at 8:32 PM, Stefan Santesson <stefan@aaa-sec.com> wrote:
> > This and the fact that it mixes the use of two extensions makes me feel a
> > bit uncomfortable with this.
> >
> > Is there a compelling use case?
> 
> I agree that the mixing of extensions here is a little nasty. Maybe
> this is best left to the multi ocsp draft.

Although it looked like a pretty good candidate for caching,
I'm starting to believe the multi OCSP extension should take care of
this optimization.  The ClientHelloExtension container of that
extension should provide room for (at least) two pieces of
information:  A limit/constraint for "producedAt" and a hash of
either the server certificate or whole server certificate chain
which the client expects to receive from the server and for which
the client still has OCSP responses cached that it considers
acceptably fresh.


-Martin