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

"David A. Cooper" <david.cooper@nist.gov> Mon, 28 October 2019 14:55 UTC

Return-Path: <david.cooper@nist.gov>
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 5C4C81208E1 for <pkix@ietfa.amsl.com>; Mon, 28 Oct 2019 07:55:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov
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 I7BTsCwEmEHx for <pkix@ietfa.amsl.com>; Mon, 28 Oct 2019 07:55:54 -0700 (PDT)
Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2119.outbound.protection.outlook.com [40.107.91.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 797161208DC for <pkix@ietf.org>; Mon, 28 Oct 2019 07:55:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mGS3WFFhCT3JJUMVvapBRBw6QCOyA7OKEh20JgsF/EE4mi7W1JG7L92xOvYh+j7FRv85x9eTtjWt4N+B+FogatUSj6eIhL1ZAw9QQqs16Wkb+FRIGsGSHlmcYWu5GeRKlu8rFYznEfQWe4GNbAC3SQhcFEF6TZSUuuUMUfeMQpC7fyBb3gDev5zbwaQIf7nE6nw3NfK6+BlM2r75FHvBFHep4SbbvmXC2X6V/tfTXnAZEoKnhvi1BiW+biRPfzRvKGSVJ+Wfd6NDJN8Dj2RN0dUSfTQojuT9lJIK0qz1+U2x72jzail9guJ9ncSfMr4RLUoAELVscU4WBzgSs54ZUA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=imYpW4aqniCMxMATS4i/I+S1khsE/rk/hvyy0mZ53iE=; b=h1pBzbm3gQMNXdrmZOnftG7cXeU+q0KqIokR5l8Al/PcwF3lI5Q193oc4q8SPACBWWP1wTIMG3nZQXfpGDQUsR1DDKvmwFkx2wAcrF3+VMqCEyunECyUE43Zl52tJav1Z+OAEH/JRPPKgutr1L8hzo8w34wVTRpm61ghYkpqCMrK94ysPAVQ80qQCy8x0OOPYZdIMz2X7wGMzep43jwi/NUyCdsjnnHiovv+JMI6vNlzdMuqSNUpcPmnYOveZOuX1GBqsHMgY8oT4pFh61ZD9U+s/C8tcGusT42VwCULKyTkT4i9qIkxx72IkNsWvCvPyftcLe4EVu2cw0XZLg9Q/Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 129.6.16.77) smtp.rcpttodomain=ietf.org smtp.mailfrom=nist.gov; dmarc=pass (p=reject sp=reject pct=100) action=none header.from=nist.gov; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=imYpW4aqniCMxMATS4i/I+S1khsE/rk/hvyy0mZ53iE=; b=u3AIF/cyj5BtUoqHrz3vRs4+BgXxozTbXyPLCqWC0yy3LybSoPvjNKcA76oYdkuxNZOcHs3Zyw0WfVfz7MmmtTiW6Goz0XmPt/8Oy8h3GnJNfaMV3x/8WeXHc4j8PjENgtDvbSnhuT6BnvPK+WA4CWbLP+T/wAnOgsX4N5HEBPY=
Received: from BN6PR09CA0060.namprd09.prod.outlook.com (2603:10b6:404:7a::22) by BY5PR09MB4405.namprd09.prod.outlook.com (2603:10b6:a03:1dc::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.22; Mon, 28 Oct 2019 14:55:52 +0000
Received: from CY1GCC01FT011.eop-gcc01.prod.protection.outlook.com (2a01:111:f400:7d02::201) by BN6PR09CA0060.outlook.office365.com (2603:10b6:404:7a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2387.22 via Frontend Transport; Mon, 28 Oct 2019 14:55:52 +0000
Authentication-Results: spf=pass (sender IP is 129.6.16.77) smtp.mailfrom=nist.gov; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=pass action=none header.from=nist.gov;
Received-SPF: Pass (protection.outlook.com: domain of nist.gov designates 129.6.16.77 as permitted sender) receiver=protection.outlook.com; client-ip=129.6.16.77; helo=nist.gov;
Received: from nist.gov (129.6.16.77) by CY1GCC01FT011.mail.protection.outlook.com (10.97.0.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2387.20 via Frontend Transport; Mon, 28 Oct 2019 14:55:51 +0000
Received: from [129.6.105.183] ([129.6.105.183]) by nist.gov with Microsoft SMTPSVC(10.0.14393.2608); Mon, 28 Oct 2019 10:55:50 -0400
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> <1572088035404.16022@cs.auckland.ac.nz> <20191027221258.ldl2f5a3anu7qyfy@nmhq.net>
From: "David A. Cooper" <david.cooper@nist.gov>
Message-ID: <c675ac19-6326-b572-5bad-b7c96aa458ca@nist.gov>
Date: Mon, 28 Oct 2019 10:55:54 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <20191027221258.ldl2f5a3anu7qyfy@nmhq.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-OriginalArrivalTime: 28 Oct 2019 14:55:50.0158 (UTC) FILETIME=[C9C27AE0:01D58D9F]
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:129.6.16.77; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(136003)(376002)(189003)(199004)(81166006)(65956001)(81156014)(65806001)(36756003)(70206006)(45080400002)(5660300002)(106002)(70586007)(6916009)(40036005)(50466002)(6706004)(47776003)(8676002)(36906005)(316002)(478600001)(966005)(6306002)(8936002)(4001150100001)(14444005)(336012)(2351001)(2361001)(76176011)(426003)(58126008)(2486003)(23676004)(21086003)(229853002)(2870700001)(126002)(6246003)(11346002)(446003)(186003)(476003)(2616005)(956004)(86362001)(2906002)(31696002)(356004)(53546011)(486006)(26005)(305945005)(31686004); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR09MB4405; H:nist.gov; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; MX:1; A:1;
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 07dcf90e-fce6-4d18-b656-08d75bb6ed3f
X-MS-TrafficTypeDiagnostic: BY5PR09MB4405:
X-MS-Exchange-PUrlCount: 1
X-Microsoft-Antispam-PRVS: <BY5PR09MB4405A7B92E3EF224E022AC4CFE660@BY5PR09MB4405.namprd09.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:9508;
X-Forefront-PRVS: 0204F0BDE2
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: Ecs8jMuYxQSXWEqbEfJN6uQ/T4f0KD+Agut0adGDG3Z+wAcPF1cz7gX8cX44MaLAddO4kIGwSRKLv8ERAve6brLzB9OqHs7pqpzntiNR8XHXxh7fewa1mxorXxUyZe59AWVmxscUAPrrG4tqtjf3oUf79bSGY7kV2ihC65J5qin0HxZa58kMI/lZYKc2CWKB4spMN2zSgvbWxefe3Asw4TuOiTvhxw9yD/+IfJgqt/cYpSD0Nogr1aFmeKNKJgbrW3z25C+hLvI0GkGvt25XRO0oTACQjEKx2is6PYz/EpFNi8iaiLYZuegQZiogk0V8Z5Enan1HbQunt9ULRY76dcOoDPWbZ3s2PgJn5pnlzqKucgZT9ijS3FzzTqO6eSMO8hQDRL1Ge42KVFQSMC+FQWLZrgy1UfN2vMGSr1ndPf4E5znhsTTuWfXFOyh8LHHZbqYUDwEqGBc8vtASQajoHOyJAi1UmtZx4UdQWeXTHzU=
X-OriginatorOrg: nist.gov
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Oct 2019 14:55:51.7754 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 07dcf90e-fce6-4d18-b656-08d75bb6ed3f
X-MS-Exchange-CrossTenant-Id: 2ab5d82f-d8fa-4797-a93e-054655c61dec
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=2ab5d82f-d8fa-4797-a93e-054655c61dec; Ip=[129.6.16.77]; Helo=[nist.gov]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR09MB4405
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/lhMfhXqqG2SuuHWFao7YjnswQQw>
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: Mon, 28 Oct 2019 14:55:57 -0000

I also don't see how this "I've checked the entire chain from the cert 
you requested all the way up to the root.  You're welcome" extension 
would work.

Consider a scenario in which a CA's private key had been compromised, 
and its certificate had been revoked. The attacker, who can use the 
compromised key to issue bogus certificates can not only issue bogus 
end-entity certificates, but also bogus OCSP responder certificates, and 
the bogus certificates can refer to the attacker's OCSP responder as the 
source for status information. The attacker's OCSP responder will 
"helpfully" says "I've checked the entire chain from the cert you 
requested all the way up to the root.  You're welcome." in order to 
encourage me not to directly check the status of the intermediate 
certificates.

The attacker's OCSP responder will tell me that the entire chain is 
okay, but the root CA would have told me that the CA certificate it 
issued has been revoked.

+-----------------------+
|                       |
|        Root CA        |
|                       |
+-----------------------+
             |
             |
            \/
+-----------------------------------------+
|          |
|    Compromised CA         |
|                                         |
+-----------------------------------------+
|                          |
             | certificates issued      |
            \/    by attacker           \/
+-----------------------+ +-----------------------+
|                       | |                       |
|    Bogus certificate  | |    Attacker's OCSP    |
|                       |    |     responder |
+-----------------------+ +-----------------------+


On 10/27/19 6:12 PM, Niklas Matthies wrote:
> On Sat 2019-10-26 at 11:07h, Peter Gutmann wrote on pkix:
>> Niklas Matthies <pkix@nmhq.net> writes:
>>
>>> 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.
>>
>> You could also do a simpler version where the responder includes an 
>> extension
>> that says "I've checked the entire chain from the cert you requested 
>> all the
>> way up to the root.  You're welcome".  It'd be fully compatible with 
>> current
>> deployments, and if clients are able to process the extension they 
>> get extra
>> value from it.
>
> In my opinion that's highly dubious, as it reverses the chain of 
> trust. Even if you trust the responder to have performed that check 
> correctly, you first have to validate the responder's signature before 
> you can trust the (signed) extension to be authentic, and for that you 
> have to validate the responder's certificate chain, which includes the 
> CA that issued the certificate being revocation-checked, and hence 
> whose validity the extension is supposed to confirm. This effetively 
> creates a cyclic dependency of trust.
>
> Suppose that the responder has been compromised (and that it has the 
> ocsp-nocheck extension): Then if the CA certificate is revoked due to 
> that compromise, a client trusting the extension won't notice, as the 
> compromised responder will happily (and falsely) assert that it has 
> successfully checked the CA chain.
>
>>> 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.
>>
>> At one point this was tested and the it was found that the number of
>> responders/clients who could handle more than one entry per OCSP 
>> query and who hadn't been set up explicitly to work with the 
>> Indentrus trust model, which requires multiple entries, was 
>> approximately zero. 
>
> Having implemented such a client myself, I have to concur. :)
>
> Niklas
>
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fpkix&amp;data=02%7C01%7Cdavid.cooper%40nist.gov%7C2fb50645c09a42b2aa8008d75b2ae66d%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637078112122458384&amp;sdata=BmfMVlkZJtYAzOByzxCk5aa6aXFCWOJDxUIVXxxM9vQ%3D&amp;reserved=0 
>
>