Re: [TLS] TLS Cached Info Status

Hannes Tschofenig <> Thu, 17 October 2013 16:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ADFEC21F9D11 for <>; Thu, 17 Oct 2013 09:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hYXKqL+tSO0t for <>; Thu, 17 Oct 2013 09:14:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1B61E21F9D0A for <>; Thu, 17 Oct 2013 09:14:01 -0700 (PDT)
Received: from [] ([]) by (mrgmx101) with ESMTPSA (Nemesis) id 0MB2G8-1VPAi93xYK-00A0IP for <>; Thu, 17 Oct 2013 18:13:58 +0200
Message-ID: <>
Date: Thu, 17 Oct 2013 18:14:28 +0200
From: Hannes Tschofenig <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: Sean Turner <>
References: <trinity-fa871610-7909-4057-89c1-4fb67302e61a-1368530285754@3capp-gmx-bs48> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:MOZ+upSJtJtIcfyBWbpGThdJfup/nT3Cv3Jrxk3/fU5Q9oU77Eq H4IGOKEXUM/C1NnH/y5FvuHBaCyrn8mGRCDOA7MWDZo2a9jA5h3jkLAPYKfpizI230RC9mP G5p9GEmJfRUv/VqB6zSIKMpnzJyk62LwNTvizxzpC+9bUuG71mJbPtO5vqEqN3tGREUf0YB WL5qsPbpZNY6lRXSuGwZg==
Cc: "<>" <>
Subject: Re: [TLS] TLS Cached Info Status
X-Mailman-Version: 2.1.12
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: Thu, 17 Oct 2013 16:14:06 -0000

Hi Sean,

here is my plan B: we go ahead with the publication of the document 
without the proposed functionality since we have not gotten the data to 
judge whether it is a useful extension or not.

We can still try to gather the data and if it indeed turns out that the 
functionality is useful then there is always the possibility to add an 
extension; the draft defines a 'lightweight' way to provide new caching 

I am going to refresh the document.


On 10/08/2013 11:40 PM, Sean Turner wrote:
> Hannes,
> Did you ever get any of the telemetry data?  If not what is plan b?
> I'd like to see this draft progress soon, assuming there's wg support
> for it, or to officially have it declared dead.
> spt
> On 5/14/13 7:18 AM, Hannes Tschofenig wrote:
>> Hi all,
>> I thought it would be a good idea to let the group know what the status
>> of the TLS Cached Info draft is (since Rob just asked me a few minutes
>> ago).
>> You may recall that we had a discussion about the ability to not only
>> cache a single OCSP response (as defined with RFC 6066) but also OCSP
>> responses of intermediate CA certs, which is functionality
>> provides.
>> Rob raised this issue in his review, see
>> To me it sounds reasonable to add the requested functionality and the
>> pros & cons had been discussed on the list.
>> When I met Ekr at the recent NIST workshop we briefly spoke about the
>> TLS Cached Info document and how to progress it. He came up with the
>> idea to use the Firefox telemetry feature to gather some data so that we
>> can estimage the cache hit/miss ratio. With data we would obviously be
>> in a much better position to make an informed decision.
>> I hope that we get that data soon. If we cannot get it then we have to
>> switch to plan B.
>> Ciao
>> Hannes
>> _______________________________________________
>> TLS mailing list