Re: [TLS] Justification

Adam Langley <agl@google.com> Wed, 12 May 2010 16:17 UTC

Return-Path: <agl@google.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 C040C28C3B4 for <tls@core3.amsl.com>; Wed, 12 May 2010 09:17:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.933
X-Spam-Level:
X-Spam-Status: No, score=-103.933 tagged_above=-999 required=5 tests=[AWL=0.556, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 cd67sxHpMLtw for <tls@core3.amsl.com>; Wed, 12 May 2010 09:17:11 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by core3.amsl.com (Postfix) with ESMTP id 3468428C2CF for <tls@ietf.org>; Wed, 12 May 2010 08:58:44 -0700 (PDT)
Received: from hpaq3.eem.corp.google.com (hpaq3.eem.corp.google.com [172.25.149.3]) by smtp-out.google.com with ESMTP id o4CFwXlV005685 for <tls@ietf.org>; Wed, 12 May 2010 08:58:33 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1273679913; bh=GTa1n6XS/OJXjOTyPoSNnPNPuy8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=dVHVcSIFELmldaGPdfODlZkknPzhg8mE7heyC3qwdnC8LiLOwTG/9e5oqt+eUSl1e jdozKN5yOJoiImNPXdyPw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:date:message-id:subject:from:to: cc:content-type:content-transfer-encoding:x-system-of-record; b=W524bweOhvCrQBGF6KljwprHZ5+UZ9OLo2qel54WdCNn4CYyp3PBDU5gxHxPRJonE QRDtmk6mC6X45g9ri5uUA==
Received: from ywh6 (ywh6.prod.google.com [10.192.8.6]) by hpaq3.eem.corp.google.com with ESMTP id o4CFwUbe007786 for <tls@ietf.org>; Wed, 12 May 2010 08:58:31 -0700
Received: by ywh6 with SMTP id 6so42504ywh.16 for <tls@ietf.org>; Wed, 12 May 2010 08:58:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.253.18 with SMTP id a18mr11178598ybi.330.1273679910692; Wed, 12 May 2010 08:58:30 -0700 (PDT)
Received: by 10.150.183.14 with HTTP; Wed, 12 May 2010 08:58:30 -0700 (PDT)
In-Reply-To: <004901caf1ea$783e23a0$68ba6ae0$@briansmith.org>
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>
Date: Wed, 12 May 2010 11:58:30 -0400
Message-ID: <p2xa84d7bc61005120858v2ce68cf7xe6ddf559faf4d4b0@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
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 16:17:12 -0000

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.


AGL