Re: [TLS] New Cached info draft

Martin Rex <mrex@sap.com> Tue, 30 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 CAFC63A692E for <tls@core3.amsl.com>; Tue, 30 Mar 2010 12:08:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.501
X-Spam-Level:
X-Spam-Status: No, score=-8.501 tagged_above=-999 required=5 tests=[AWL=0.618, 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 tFT1AEaj+xXd for <tls@core3.amsl.com>; Tue, 30 Mar 2010 12:08:33 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id A9D1F3A68EC for <tls@ietf.org>; Tue, 30 Mar 2010 12:08:23 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o2UJ8n9b000573 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 30 Mar 2010 21:08:50 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003301908.o2UJ8n4K013702@fs4113.wdf.sap.corp>
To: brian@briansmith.org
Date: Tue, 30 Mar 2010 21:08:49 +0200
In-Reply-To: <002201cad028$d20eb950$762c2bf0$@briansmith.org> from "Brian Smith" at Mar 30, 10 11:48:26 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
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: Tue, 30 Mar 2010 19:08:34 -0000

Brian Smith wrote:
> 
> Adam Langley wrote:
> > One last point, I think I'd like to see the ability to cache the
> CertificateStatus:
> 
> Optimally, the client only really wants a certificate status update when a
> previously-cached one has expired and/or the server's certificate has
> changed. Server certificates very rarely change. Consequently, the client
> should be able to get by with sending the certificate status request
> extension only when it doesn't have a non-expired certificate status for
> that server, right? AFAICT, this would work equally well for servers that do
> and don't support the cached-info extension.
> 
> Please let me know if I am overlooking something.

The cached info uses a fail-safe approach in that the real data will
be sent by the server when the information by the client does not
match (based on the server comparing the hash values supplied by the
client).

You can not do that with the TLS extension for OCSP.  The client only
knows what certificate the server from the reply to the ClientHello
handshake message.  IMHO, the robust approach for a TLS handshake
that has the highest likelihood to succeed, requires the use of
the TLS extension for OCSP plus the caching extension for
the actual extension contents (the OCSP responses).

I would not want to go through a handshake failure when the
OCSP responses that the client has cached are still valid, but
the server has switched to a different server certificate
since the last connect.


-Martin