Re: [TLS] New Cached info draft

"Brian Smith" <> Tue, 30 March 2010 20:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E74F83A6A91 for <>; Tue, 30 Mar 2010 13:24:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.111
X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Y6+5Nn1trBm for <>; Tue, 30 Mar 2010 13:24:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 16D873A69EC for <>; Tue, 30 Mar 2010 13:23:48 -0700 (PDT)
Received: from T60 (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 4D240509DC; Tue, 30 Mar 2010 16:24:11 -0400 (EDT)
From: "Brian Smith" <>
To: <>, <>
References: <002201cad028$d20eb950$762c2bf0$> from "Brian Smith" at Mar 30, 10 11:48:26 am <>
In-Reply-To: <>
Date: Tue, 30 Mar 2010 15:24:10 -0500
Message-ID: <003c01cad046$f7c12980$e7437c80$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
thread-index: AQG6F37WGb5SNzh5Ecjyu3+4NDgR1gFVPxQ0ASuwQC4=
Content-Language: en-us
Subject: Re: [TLS] New Cached info draft
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Mar 2010 20:24:33 -0000

Martin Rex wrote:
> 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).

My concern is that a hash of the client's cached value compared against a
hash of the value the server would otherwise send would not result in
optimal caching, because the server will often have an OCSP response that is
different bitwise, but which is equivalent for verifying that the
certificate was valid at the time of the handshake. Ideally, most
applications in that situation you would rather not have the server return
the newer OCSP response, because the client's older OCSP response is good
enough at the time of the request, and by the time that old response
expires, the server will probably have an even newer response. 

Instead, it would be better to have an extension that said "Don't send me a
CertificateStatus unless there was a cache miss for the certificate and/or
the certificate status has changed from X," where X is the client's cached
value of the certificate status (usually "good"). Practically, that would be
the same as " Don't send me a CertificateStatus unless there was a cache
miss for the certificate" because a good server wouldn't carry on with the
handshake if it knows it has a bad certificate, and a malicious server
wouldn't bother telling you that its certificate has been revoked.

- Brian