Re: [pkix] Optimizing OCSP - Time for some spec work ?

Niklas Matthies <pkix@nmhq.net> Fri, 25 October 2019 21:49 UTC

Return-Path: <pkix@nmhq.net>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D5E912004A for <pkix@ietfa.amsl.com>; Fri, 25 Oct 2019 14:49:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 fkhbJEkDxnA1 for <pkix@ietfa.amsl.com>; Fri, 25 Oct 2019 14:49:49 -0700 (PDT)
Received: from mail.nmhq.net (mail.nmhq.net [95.129.49.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26AC3120020 for <pkix@ietf.org>; Fri, 25 Oct 2019 14:49:49 -0700 (PDT)
Received: from matthies by mail.nmhq.net with local (Exim 4.89) (envelope-from <pkix@nmhq.net>) id 1iO7Ss-0002n0-VP for pkix@ietf.org; Fri, 25 Oct 2019 23:49:46 +0200
Date: Fri, 25 Oct 2019 23:49:46 +0200
From: Niklas Matthies <pkix@nmhq.net>
To: pkix@ietf.org
Message-ID: <20191025214946.iwxlbdvi7k42s6lb@nmhq.net>
Mail-Followup-To: pkix@ietf.org
References: <31256d2d-dcfb-85f7-3850-accb2b2d6b89@openca.org> <1571969278256.43657@cs.auckland.ac.nz> <a87cd195-8b26-6bbd-8e37-473478e1a956@openca.org> <20191025152019.pevdicon45ql6zml@nmhq.net> <4378c2a4-dc0e-4bc4-e43a-fa612cfc65dc@openca.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4378c2a4-dc0e-4bc4-e43a-fa612cfc65dc@openca.org>
X-Clacks-Overhead: GNU Terry Pratchett
X-Editor: VIM - Vi IMproved 8.0
X-Operating-System: Linux 4.4.112 x86_64
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/ep89RCyO-TaDbVHcWDyvCvvOG30>
Subject: Re: [pkix] Optimizing OCSP - Time for some spec work ?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Oct 2019 21:49:52 -0000

Hi Max,

You are right that the trust problem would be difficult, if not 
impossible, to solve when using additional single responses. Placing 
the additional responses in a response extension, as a sequence of 
basic responses signed by the respective authorized responders, 
certainly is a better idea.

However, I now see the following considerations:

1) If the up-chain responders all do the same thing, then it would be 
sufficient (and advisable) to only add one additional response for the 
immediate issuer, as that response will in turn include a response for 
the issuer's issuer, and so on. In other words, when assembling the 
response, the implementation should check which responses it needs to 
add itself and which are already part of the responses being added, to 
avoid unnecessary duplication. (More generally: to keep the response 
size linear in the chain length instead of becoming quadratic.) 
Conversely, clients would have to be prepared to collect all needed 
responses from that nested structure.

2) In case of such a nesting, the more nested a response the older it 
will usually be, due to caching at each responder. That would have to 
be taken into account when assembling the outer response, potentially 
having to replace a nested response by adding a fresher version of 
some inner response at the outer level. A similar issue exists with 
regard to nextUpdate field when a nested response expires before the 
outer one does. This increases the overall complexity.

3) When storing OCSP responses for long-term validation (e.g. in 
signature extensions for archiving), one may want to unpack the inner 
responses before storing them, so that validators are not required to 
support the nested format. However, because the inner responses are 
covered by the outer responder signature, they cannot be removed from 
the inner structure, which means they would need to be duplicated to 
also store them at the outer level, increasing the overall size.

For those reasons, in particular the fact that the structure cannot be 
disassembled without breaking the outer signature, it would really be 
simpler and more flexible to just have a linear sequence of regular 
basic responses. This could be achieved via a new response type 
(responseType in ResponseBytes) for which the response bytes consist 
of a sequence of basic responses instead of just one basic response. 
(Some additional guidance would have to be given for the certs field 
of BasicOCSPResponse so as to avoid redundancy there.)

That approach can still be specified as a profile on top of the 
existing OCSP specification. The drawback, of course, is that 
compatibility with existing clients would be lost. Note that clients 
can specify the response types they understand via the 
id-pkix-ocsp-response request extension. As OCSP responders are 
required to support the id-pkix-ocsp-basic response type (section 
4.2.1 middle paragraph), conforming responders would have to support 
two different response types. Nevertheless, it seems to me that this 
would be a simple and straightforward solution.

Cheers,
Niklas


On Fri 2019-10-25 at 12:51h, Dr. Pala wrote on pkix:
>Hi Niklas,
>
>thanks for pointing that out - that paragraph is quite difficult to 
>interpret correctly (I guess that is why nobody is attaching extra 
>OCSP responses). In fact the text reads:
>
>   The response SHOULD NOT include any additional
>       SingleResponse elements, but, for example, OCSP responders that
>       pre-generate status responses might include additional SingleResponse
>       elements if necessary to improve response pre-generation performance
>       or cache efficiency (according to [RFC5019], Section 2.2.1).
>
>and it starts with a SHOULD NOT :D I guess this was an attempt to 
>provide some capability here, but did not provide the use-case for it. 
>- therefore support for "extra" responses is quite interesting. When 
>reading this paragraph, my first reaction as a developer is NOT to 
>implement that feature.
>
>Also, if you think about it, there is a Trust problem - why shall I 
>trust this CA's responder to provide responses up in the chain ?
>
>If the inclusion of the additional responses would encapsulate their 
>authentication information, then we could trust those additional 
>responses... otherwise, if not locally configured, the responder is 
>not authoritative for other CAs. If your OCSP responder supports 
>multiple CAs and could be authoritative for all of them... which 
>certificate will your responder use to sign the response (i.e., shall 
>it use the certificate that makes it authoritative for the requested 
>certificate or the one that makes it authoritative for the issuing CA 
>status ?)
>
>Therefore, although it is technically possible, I think the way it is 
>specified now it is not really usable. Do you know of implementation 
>that use this feature? If so, do you know how they solved the Trust 
>issue here ?
>
>Ultimately, coming to using extensions in the requests - that is an 
>interesting option (what about attaching the responses of the upper 
>links in the chain as an extension in the basic response ?), however 
>this complicates the implementation server-side ==> In general, 
>whenever you add the possibility for the client to influence the 
>content of the response, responses need to be generated according to 
>the client-provided parameters, and, therefore, they cannot be 
>pre-computed (which I think can be easily implemented if the number of 
>target responses is sufficiently limited - i.e., your revoked 
>certificates population is small enough that live responders 
>calculate, cache, and update all responses 'live' with great 
>performance and that do not require lots of resources).
>
>Thanks again for the feedback!
>
>Also, would you like to contribute to the effort shall we (IETF) 
>decide to tackle this problem ?
>
>Cheers,
>Max
>
>On 10/25/19 9:20 AM, Niklas Matthies wrote:
>>Hi Max,
>>
>>Just to chime in regarding the first reason: OCSP responses are 
>>allowed to include additional single responses that weren't 
>>explicitly requested by the client, see RFC 6960 section 4.2.2.3 
>>last paragraph.
>>To make the additional responses optional (controlled by the 
>>client), a corresponding request extension could be defined. Hence 
>>that aspect could be covered by specifying a profile of the current 
>>OCSP protocol.
>>
>>Cheers,
>>Niklas
>>
>>
>>On Fri 2019-10-25 at 08:57h, Dr. Pala wrote on pkix:
>>>Hi Peter,
>>>
>>>That is a great point. I would like to explore it with you.
>>>
>>>Yes, it is possible. However, I think that did not work for two 
>>>reasons. If I am not mistaken (please correct me if I am wrong), 
>>>the first reason is that the client has to explicitly request the 
>>>responses for the certificates in the chain (i.e., multiple 
>>>requests). The second reason, I think, is related to the trust 
>>>model: the responder have to sign responses from different CAs 
>>>instead of just one - so how can I trust the response from an 
>>>intermediate CA to guarantee me that all CAs above me (me 
>>>included) are not revoked ? It might work if you use a RootCA to 
>>>sign the responses... but it is not common to use the RootCA keys 
>>>directly... In addition to that, each certificate carries the 
>>>indication where its revInfo can be retrieved, therefore clients 
>>>tend to make single requests to the different OCSP responders one 
>>>by one (it might be the same, but it might be different). In 
>>>addition to this, there might be implications about pre-computed 
>>>responses
>>>
>>>As far as I know, as you say, it is possible, but I have not seen 
>>>clients actually querying for multiple certificates - have you ?
>>>
>>>A different model would be for the OCSP responder to be able to 
>>>retrieve (maybe if requested by the client w/ an extension) the 
>>>additional responses (as the client do today) at regular intervals 
>>>and attach them together with the response for the request from 
>>>the client. This allows to have different validity period of the 
>>>responses and no real trust-related dependencies (i.e., the OCSP 
>>>responder will re-fetch the responses that are expired and maybe 
>>>cache them for the validity period or part of it).
>>>
>>>From a developer point of view, maybe this approach can provide 
>>>easier (for the developer) query mechanism (i.e., "What is the 
>>>Revocation Status of Certificate X ? Can you include the responses 
>>>for the full chain ?" instead of ""What is the Revocation Status 
>>>of Certificate X, Y, and Z ?" - not being sure if this is the 
>>>right responder for all of them)).
>>>
>>>Does that make sense ?
>>>
>>>Cheers,
>>>Max
>>>
>>>
>>>On 10/24/19 8:07 PM, Peter Gutmann wrote:
>>>>Dr. Pala <madwolf@openca.org> writes:
>>>>
>>>>>Providing Full Chain responses.
>>>>OCSP already does this, and has done since day 1.  That was the 
>>>>Identrus
>>>>value proposition, they would do all the checking for you and return
>>>>everything in a single response.  It proved... less than wildly 
>>>>popular.
>>>>
>>>>Peter.
>>>-- 
>>>Best Regards,
>>>Massimiliano Pala, Ph.D.
>>>OpenCA Labs Director
>>>OpenCA Logo
>>
>>>_______________________________________________
>>>pkix mailing list
>>>pkix@ietf.org
>>>https://www.ietf.org/mailman/listinfo/pkix
>>
>>_______________________________________________
>>pkix mailing list
>>pkix@ietf.org
>>https://www.ietf.org/mailman/listinfo/pkix
>-- 
>Best Regards,
>Massimiliano Pala, Ph.D.
>OpenCA Labs Director
>OpenCA Logo

>_______________________________________________
>pkix mailing list
>pkix@ietf.org
>https://www.ietf.org/mailman/listinfo/pkix