Re: [Sidrops] what to do when the CRL is hosed?

Stephen Kent <stkent@verizon.net> Wed, 26 February 2020 17:03 UTC

Return-Path: <stkent@verizon.net>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05233A0C3E for <sidrops@ietfa.amsl.com>; Wed, 26 Feb 2020 09:03:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 SV5pb3ocbRSP for <sidrops@ietfa.amsl.com>; Wed, 26 Feb 2020 09:03:38 -0800 (PST)
Received: from sonic303-2.consmr.mail.bf2.yahoo.com (sonic303-2.consmr.mail.bf2.yahoo.com [74.6.131.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C4153A0C07 for <sidrops@ietf.org>; Wed, 26 Feb 2020 09:03:38 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1582736617; bh=7WlOx5qqP3m3cVLQdxKHmGp5HlYQEc1ZmIfil16/itc=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From:Subject; b=V6sFMvWJBL+LyqzBVgQBR6rlx7LGrh7wMD1XFsdxv6jPKZaxqiUaqJeIro+4/zq2glJv92T3fAhH/7roBGZTF1FCeKOpkRSwAEXB7B6fnp4q0mTNZWq9yyBIpUn8HISzM6/w7KnxQNvzp/F1mCLomt0qy30no2G/sQphWrqU2E2Ui5dabHxMVEtVvYyQroHL3bEAu1l0+6+cKBsrVnUdC+DoLAI9BpXrBBgj/bcMrKJx70pi7p+2dMKtH0Q4NowsWADn4mOra7vVLisUg5E84Ang5mqiQEP/3WDmBD8Ad/4Lrz/NoysB1pEIUdtcBYHZjZpJZ4FdDT31nE0Rvy1o1A==
X-YMail-OSG: bxUjFAUVM1k7EzHHbwB84cz95p99tXY3eOU394cyehonWmqRq3cCWeTtEFMPVHF WVuilvJLwdJyFlv2zaZ4N7yWv31AYLny0h.nQeafrjA57BUVHpC7J6np90NkLas3UpUB8_rvfKpI lXa3s3HGWBTNrJJjJ2SI6TxMTP8YjnvxqCbxp2UGdAGyNa1HmcnsBh9o.QkqBYHnImqSy2nmbzW3 1RkBysonUoHj8RD9e8ktB0vLVFTtpzkYv3egJ5HRXrf2iDPGYDugMxxRxiAQVO3oWG.WMoSyLLba qPqtUbBd_fKr.uH5C7DIqY.3CgdC1wefSJcLA5xHn191iiJCKPaf6.W._J4S80WDfHhCneSZN1q0 eUvwwPssVJkydfuBq2R_g2KdMsnN.EW0nHzbFRDjRRA79xwd8Ge3pHLn2QkJFUna7wjndG1VHb_. tLcaWq7GxzjPTtG61WwS7otm41ujJKuiz28OtY37vhFYATPkzDIdRXDl7vR484V6bK1OXE9WZ2uQ 0Cnl92vp1NI49VAJiWVPuCz.01LzLnClVPdfIVYRw1FBAixGc57uZy8zK6wCxN5FWZcJM5vhYzAB fI41o7heGRsKE4q6AEMujKimF61B5tm2z780knFAPKGhBQl8Jmf4LETzbGzxp5CB8Ga6GJSjHE5L FD9kbGQyeSIikMxs9_iWa_0ZfJfFCnbxQKLGhbox.7UQUCrAhhrHDHjKbqfYFSkVFpMH1j9BhJ6. 0g9qIDB5ZIO2lWaUZP2TYbZp3C3sT.hzuLV745uQqLE1PMmtUT6hoIvTi7zxCl4ISpKBqcEMQDT6 s_O7_1LxUxkNmLJzjl0tWOgkOZtZDApa7pY2wTae6tKlUS.xXKkLysL3xNas9pOb1Ixs_i.gEMzC u1IahtAvTdrqjU2GB0jsGE6G6z80iuidb0_ywlpl5lQee9iJr55njY0kZfC1uaPor50_vceo1FrB PznPGTiW30YRMWe_zx.5bVdH.g61r53E9qZ45ZUZMVDbNVnrsjU8xpXHh691oKI15wlKngqmsP1J S6386t8IhowgdGARZpdZOqlaRQhNBfitc6VaapXURgOdjOUfcSKRWcf8mJHg.HICiqPZO9UKXsZF hrcvwHTkAid8ltStoA7KzSeG1imhxxna2T3xg6GaMO1ggiOjdViSmClr1Wudcgv9Y89fO1_ne87E 1F7.mp16T4lipYrkcoNn4hgJ.b4H8bqU1Ca8Teg9j7NSNkto15bYumWUKpnwmzNUwjbn4KQSgZkB wwRxyYrYlnJ3GDsZ9zx2lPtwuKotmh2m7IfSg3CwX.sJlw63pfO17gYvJIX0TNGaMDHXcRO5Lpbu WuH0XAsRbdBsHddV.0X6eGrrwEDxoL0WXnYVXw3Qu9R0VYCm7f2TPMjZch6aZKHzNtUxFVVU7s_r uqD61rzh36iqnkzaW7ucfxOf7yVo.Kc1jOKXT
Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.bf2.yahoo.com with HTTP; Wed, 26 Feb 2020 17:03:37 +0000
Received: by smtp418.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 83f24b3b8b0e9039caa8051553f64758; Wed, 26 Feb 2020 17:03:33 +0000 (UTC)
To: Tim Bruijnzeels <tim@nlnetlabs.nl>
Cc: sidrops@ietf.org
References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl> <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net> <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <6602d1a7-ecbf-73a0-21d8-1254fb2aff97@verizon.net>
Date: Wed, 26 Feb 2020 12:03:33 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <3B7006DE-5366-47E7-9CD6-AF392F9ED0CC@nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Mailer: WebService/1.1.15302 hermes Apache-HttpAsyncClient/4.1.4 (Java/1.8.0_241)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/QdGzE132YzW_BW7p6I_CZDugdno>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Feb 2020 17:03:40 -0000

Tim,

Thanks for your thoughtful analysis of the options. Her are some 
additional thoughts.

In general, a stale CRL still represents the best info re revoked certs 
available to an RP, so ignoring it does not seem appropriate, to me.

In the RPKI we also have Manifests, so if a Manifest is current but the 
CRL it references is stale, then that strongly suggests that the CA has 
encountered a problem generating a new CRL, but it's still the best 
revocation status info available, so use it and consider contacting the 
CA (via the GB record) to point out this problem.

A CRL is invalid if it's signature doesn't verify, or if it has a syntax 
error, even in the face of a valid sig. In this case I would ignore the 
CRL contents, contact the CA, and keep using the freshest CRL the RP has.

Because these CRLs MUST contain sequence numbers, receipt of a valid CRL 
that appears to be current, but has an older (or the same) serial number 
relative to a previously validated CRL is suspicious. I would 
definitively contact the CA to see if it just forgot to increment this 
field properly. I probably would stick with the freshest CRL info I had 
for that CA until the matter is resolved.

There are more cases one can analyze, but I think the basic approach is 
to stick with prior, validated CRLs and contact the CA that issued the 
questionable CRL, until the matter can be resolved.

As for the considerable leeway accorded to RPs in the Manifest document, 
I concur that it allows inconsistent local behavior. If the WG can agree 
on more proscriptive language, that would be good. When we wrote 6486 we 
were unable to agree on such, as we tried to balance robustness vs. 
responses to possible active attacks on repositories or communications 
between an RP and a repository.

Steve