Re: [TLS] Justification

"Brian Smith" <brian@briansmith.org> Wed, 12 May 2010 17:26 UTC

Return-Path: <brian@briansmith.org>
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 AB0B028C160 for <tls@core3.amsl.com>; Wed, 12 May 2010 10:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.742
X-Spam-Level:
X-Spam-Status: No, score=-0.742 tagged_above=-999 required=5 tests=[AWL=-0.557, 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 mgW+tnByaKzN for <tls@core3.amsl.com>; Wed, 12 May 2010 10:26:02 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id E7F4528C184 for <tls@ietf.org>; Wed, 12 May 2010 10:01:23 -0700 (PDT)
Received: from T60 (unknown [70.245.69.20]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6FEAE509DC; Wed, 12 May 2010 13:01:06 -0400 (EDT)
From: "Brian Smith" <brian@briansmith.org>
To: "'Adam Langley'" <agl@google.com>
References: <20100510221531.GC9429@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> <n2va84d7bc61005120811o737c2011i27f9d40e88417539@mail.gmail.com> <004901caf1ea$783e23a0$68ba6ae0$@briansmith.org> <p2xa84d7bc61005120858v2ce68cf7xe6ddf559faf4d4b0@mail.gmail.com>
In-Reply-To: <p2xa84d7bc61005120858v2ce68cf7xe6ddf559faf4d4b0@mail.gmail.com>
Date: Wed, 12 May 2010 12:01:07 -0500
Message-ID: <006501caf1f4$b9ad3150$2d0793f0$@briansmith.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHHMro8BXdqp6B5/qHhToooO2CPmgGfG5qMAaJ7oHgBywOFAwFvQCN6Al9XCi8CV+kowwInHXWlAcqsZDQBQ8brsAG7bSMGAl3emYc=
Content-Language: en-us
Cc: 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:26:03 -0000

Adam Langley wrote:
> On Wed, May 12, 2010 at 11:47 AM, Brian Smith <brian@briansmith.org> wrote:
> I don't think that a caching mechanism based on hashing the OCSP responses is
> going to be optimal for this. A different caching mechanism that allows the
> client to ask specifically for only *newer* (not just *different*) OCSP responses
> would be much better.
> 
> The specific case that I'm worried about is a client connecting to a
> server for which the previously cached OCSP responses have expired.
> 
> As an example, consider a server which returns two certificates: 806
> and 807 bytes long. The OCSP responses for these certs are 1085 bytes
> long. So the total return is 3783 bytes, not including the overhead of
> the ServerHello etc. This is very close to the three packet limit.

Yes, I understand. But, just because the server has a different OCSP response, doesn't mean that it's OCSP response is better than the cached one. For example, two responses could have different producedAt times but the same thisUpdate/nextUpdate times. Or, even thisUpdate might be slightly newer, but not enough to make it worthwhile to download it. AFAICT, optimally the client would ask for an OCSP response with thisUpdate >= X, where X is some time significantly later than its cached OCSP response's thisUpdate but before its cached OCSP's responses nextUpdate.

At any rate, I think it would be better to discuss the optimal way of caching OCSP responses first, independent of syntax. Then it would be clear whether this syntax or another one would be best.

Regards,
Brian