Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare)
"Dr. Pala" <madwolf@openca.org> Wed, 20 November 2019 06:47 UTC
Return-Path: <madwolf@openca.org>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F8120125 for <secdispatch@ietfa.amsl.com>; Tue, 19 Nov 2019 22:47:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.437
X-Spam-Level: *
X-Spam-Status: No, score=1.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hOkwBC36N4Z for <secdispatch@ietfa.amsl.com>; Tue, 19 Nov 2019 22:47:08 -0800 (PST)
Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id B5EAE120255 for <secdispatch@ietf.org>; Tue, 19 Nov 2019 22:47:08 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 85BA537413B5; Wed, 20 Nov 2019 06:47:08 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id iGVWyEOjdX4m; Wed, 20 Nov 2019 01:47:07 -0500 (EST)
Received: from Maxs-MacBook-Pro-2.local (unknown [101.100.166.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 1000537408D6; Wed, 20 Nov 2019 01:47:05 -0500 (EST)
To: Nick Sullivan <nick@cloudflare.com>
Cc: IETF SecDispatch <secdispatch@ietf.org>, Tim Hollebeek <tim.hollebeek@digicert.com>
References: <265ce9c3-8d24-b8c2-f13c-a54280a7ffba@openca.org> <CAFDDyk9x1w-voWdM31zwExkj3UWX9Dir4d4JF2DQrxYArH-jbg@mail.gmail.com>
From: "Dr. Pala" <madwolf@openca.org>
Message-ID: <5e81fda8-52d3-e39a-1999-ac98efd4ae70@openca.org>
Date: Wed, 20 Nov 2019 14:47:03 +0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <CAFDDyk9x1w-voWdM31zwExkj3UWX9Dir4d4JF2DQrxYArH-jbg@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------1524C40E438E389B70EB9251"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/BA1K9Lc-n25MVnLzHHYWosfbaBY>
Subject: Re: [Secdispatch] Clarification for a question about OCSP caching from Nick (Cloudflare)
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Nov 2019 06:47:10 -0000
Hi Nick, thanks for the reply. My comments are inline... On 11/20/19 1:07 PM, Nick Sullivan wrote: > Hi Max, > > Thanks for your clarification. I now understand the work is aimed at > optimizing the number of signatures by the CA's OCSP responder and the > number of bytes of unique OCSP data. > Yes, that is correct. The other optimization is about the ability to provide responses for the whole chain in a single message. > Currently, the number of OCSP signatures the CA needs to do is linear > in the number of active certificates. This proposal changes this so > that the number of signatures is linear in the number of revocations > of active certificates. It's conceptually similar to NSEC in that way: > it's a cover proposal in which the artifacts are constant size, but > require a linear number signatures in the size of the revocation set. > Contrast this with CRLs, which require a constant number of > signatures, but are linear in the size of the revocation set. So maybe > the goals could be better phrased in terms of _/lowering the cost of > /*generating*/ compared to OCSP and /*distributing*/ compared to CRLs/_. > I am not sure I follow. In PKIs, today, we use both mechanisms. This is because usually the CRLs are used as a backup mechanism for OCSP - we also need to support both because of Certification Policies (exactly as in the Internet PKI environment), therefore it is not a choice :D The proposed approach can be used to (a) limit the amount of data that needs to be generated, stored, and transferred when pre-computing responses, and (b) to compute all responses and serve them from memory - even small instances without any hardware acceleration could achieve reasonable performances (also for shorter validity periods in responses). > This proposal implies a middle-ground PKI deployment that has enough > revocations for CRL to be inefficient but not enough to cause the > negative space of the serial number to be of the same order as the > number of certificates. It would be great to see examples of PKIs that > motivate this optimization, which is why I suggested that data could help. Technically, you are correct. If we could predict the size of CRLs, we could potentially try to understand what that threshold is. However, as I explained in the presentation, the size is fairly unpredictable. That is why we primarily use OCSP today. > > I should also note that while this proposal reduces the number of OCSP > signatures (which can be on the order of 104 signatures for 2-year > certs), the impact is less dramatic for CAs that issue shorter-lived > certs. For example, Let's Encrypt only signs around 13 OCSP responses > for each of their 3-month certificates. That is correct, the impact is less with short-lived certificates because in those environment, the population of active certificates is usually smaller. If the population is still large, you still have the same problem. You mention that your OCSP responses have a 7 days validity, correct ? My question is: which considerations went into deciding such a large validity period for the OCSP responses (7 days) ? Maybe costs considerations drove the decision ? From a security standpoint, such long validity periods blinds clients from detecting revocation that might happen during the 7-days validity period (the problem is worse now with the deployment of OCSP stapling because clients do not fetch fresh responses at connect time, AFAIK, if stapling is supported). I would expect that few minutes validity windows or maybe few hours would be a better choice - but how much does that cost to Let's Encrypt ? The Cable industry has used certificates, for few decades now, for different purposes - as a hardware certification tool and to secure our networks - in this environment, the typical life-span of a certificate is many years (up to 20) and it is tied to the envisioned life-span of the device (no renewal). As you can see, in our environment, CRLs will never be an option and OCSP simply costs too much (for an infrastructure that, over all, has an active population of several hundreds million of active certificates - we might be even beyond that with just the three OpenCable, PacketCable, and DOCSIS). Ultimately, we need to work on the solution so that we can have our vendors to integrate it in their products, like CableModes, that are going to be deployed (and provide internet connectivity) for hundreds of millions of households for the next 10 to 20 years. We need to lower the security risks associated with the infrastructures that brings Internet to many of us - revocation is important to prevent possible compromises to go undetected. I think that everybody who has Cable should support this work that is going to directly impact them for many years. Cheers, Max P.S.: I also have other personal motivations for this work. I think that this is also the right thing to do for non-technical reasons - I come from the OpenSource world that so much has give for the success of the Internet but where there is no money. More efficient technologies could be leveraged by communities around the world who deserve good security but costs get in the way. I know it is not a technical detail, but I think we shall always try to have these considerations in our minds - making the world a better place and less wasteful (energy) is an amendable goal in general and emerging communities could really benefit from our work. > On Tue, Nov 19, 2019 at 9:11 PM Dr. Pala <madwolf@openca.org > <mailto:madwolf@openca.org>> wrote: > > Hi Nick, all, > > at the end of the second presentation on lowering the costs of > revocation, if I am not mistaken, your question/comment (Nick) was > about the fact that Cloudflare hosts / serve most of the cached > OCSP responses and that the system does not have issues. > > I am not sure if this comment is pertinent to what we are trying > to solve here... let me elaborate a bit more. > > The work we have been doing around the proposed topic of work is > aimed at /_lowering the cost of *generating* and *distributing* > these large volumes of signed data_/ when there is actually no > need for that. By optimizing the protocol to provide range > responses (or other methods, if we decide to go with a different > approaches), we can reduce the number of signatures needed from a > CA and their distribution - very expensive operations. > > In other words, the proposal is /_not aimed at fixing any caching > issues_/ because, as you noticed in your comment, that works just > fine. The proposal at hand, instead, is about fixing a problem > that CAs are facing today - high costs of deploying and running > such systems. > > On the other hand, your comment made me think about the caching > service you mentioned and its associated costs. > > Is it a service for which your company charge CAs ? If so, would > you be able to share what are currently the costs incurred by CAs > to leverage your service ? (I totally understand if you are not > willing to - after all, this is usually the secret sauce :D) > > Last but not least, I also would like to point out that optimizing > the revocation can also help open-source communities, small > companies, universities, non-profit, etc. by enabling them to > deploy cost-efficient systems that can provide good quality of > service using less resources (computational, storage, network). > > Please let me know, > > Cheers, > Max > > P.S.: If we could combine this idea with OCSP over DNS, we could > really provide access to revocation technology for everybody, not > just who can afford the price. Unfortunately we know how that > discussion went, and I still think it is a very evident mistake > not doing it (I am still working on this in my spare time - I > think it is of enormous value for emerging countries to have > access to cheap secure technologies and, in my opinion, IETF is > dropping / has dropped the ball on this for not-so-honorable > reasons, I suspect...). I hope We can fix it in the open-source > community. > > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > OpenCA Logo > -- Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo
- [Secdispatch] Clarification for a question about … Dr. Pala
- Re: [Secdispatch] Clarification for a question ab… Nick Sullivan
- Re: [Secdispatch] Clarification for a question ab… Dr. Pala
- Re: [Secdispatch] Clarification for a question ab… Carrick Bartle
- Re: [Secdispatch] Clarification for a question ab… Eric Rescorla
- Re: [Secdispatch] Clarification for a question ab… Tim Hollebeek
- Re: [Secdispatch] Clarification for a question ab… Michael Richardson
- Re: [Secdispatch] Clarification for a question ab… Eric Rescorla
- Re: [Secdispatch] Clarification for a question ab… Carrick Bartle
- Re: [Secdispatch] Clarification for a question ab… Carrick Bartle