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

Stephen Kent <stkent@verizon.net> Tue, 25 February 2020 16:56 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 F03073A1067 for <sidrops@ietfa.amsl.com>; Tue, 25 Feb 2020 08:56:04 -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 MMPAMO79LbFa for <sidrops@ietfa.amsl.com>; Tue, 25 Feb 2020 08:56:03 -0800 (PST)
Received: from sonic311-14.consmr.mail.bf2.yahoo.com (sonic311-14.consmr.mail.bf2.yahoo.com [74.6.131.124]) (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 B391B3A106B for <sidrops@ietf.org>; Tue, 25 Feb 2020 08:56:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1582649762; bh=Ifw3k6n4WeQhoXRqouwRep4XRf8SW270DF6nQuZxUU0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=eVUaUaEBRs9L8g6tVgVUqoe70a5ipImruHOAHHGRqnYvMCKIcBMdz99L2s2ng3C5ENPd1SI/RSIrFiYGLEv+fqyKGq6YvhZgYxO+KnKVCdBz4KJO325t4LrGlBWgHL3ofCGprtS0wX2joNkos9FXZ16rO0aWO5SmzFW75c94RO4gwe9LUcQLUEr2QJ/pwEqjdOICqrx1Cf5XBzYEWXbUFZalpvwbEtUeuHRc7C37tDrF5TUMjipd9MFEir9rj+FcSNvDPf+0O+8w/8OsvUTcw6k3eruhJ4MF3jRiO+sI64QMZH1g7bbV0fe8uzN2G4pxwyDbimrWQ7C5DRI92B/Jbg==
X-YMail-OSG: Fqunmi8VM1mSSIbbOwE7M_mk7PmztgRL6fT6NLLeyivr2DgA2F661HLC6Utsjrg W5ylYZc.br7s06MQC1vxKWIgFG3uCDbMQjukVPBxkGWJQlEB1_7ua2n9m06.FcCiEc1orjDoWRXJ aqBciOk.FXIRAht4L1Wh403VY_N0I9UFfpnk2j9ETTcbhNynNka0dC8uzjmfyKToGl9I1C415ERu 1jsB0cuwrnBGbCa8YtOLn9ilVbgitxpVQnrv3Te00xN74eAba3X8dTallceVjDz_5pW7kpRgu3iR zsfC55RvuuRXD8Gi0hsdXuLj_WeWDytly81X_u31nmjCx6rktLMsE0S7WyOJDMYu.H7Ca4Hdhwai S.eiVNL4P8RVID75MKGrblI_omgFVwntIyYp9gB2KDfDE_dMPtatf18eNmY4Ygfz8MwOqEcFot5W CozM5jSBQqRN_pdLObAkfpojeQNF2KG7Z9hIxVoYAuLmv9DgIwEugceHs4ih7FfrhMNnFZJ4apwG CgjY0ZJ5LaKNOjmPgC5K_MTPM0StjvGyYAJtErgCntos2uW9wfeQzwFOc6hY_JO6AN3b8ZyAq9gC ieUIQGMe1QYkCsuBK.sGeDdrds0AL6qT87PesSX25JurT_Ul9wdH0LRtGEwrPthfV6ea0yT39uv4 tnxdtv1yUt.vNh73Hik6_rqGoQ9b9p6Od74jPtuu5B3jBnsaHNddQFOrW3ITCommAmTo9Zp2O77h tQG7nayKMx.6yUcpETpTmQQ5M8065pCWqVgZnA6RyEb6vMsw.ZikxASxbZ65dBCKhukivTOHjgrs jyOobieLUvMnnSPE8Y_sysUDGFllM8ip4vd__2e0EsyXCbw.OD8PJ_cVuq_wabPJ6eqghep.to6v ydgseAZ11biP.iRQg60IwPL1L48ObOjq1CsTf7B.YSXoRQ2C_tCxE.SUH3UvEpCKTBryOB9SiofY XXN_HRxUG00rsa8eHQg2msC21Bcu8xxV35gVOt_BAngCv5P43.LXz0mOSTTBmOKbxcKt9ttnYPob Gwd7smnMuFEDD1yjG1QMoFZVcQaisj3Xx3Fiey9bMo_A3R0YmnTOKT455bvsAVGxrhE3Q8dPR2FR Xz5M.3QBrXTwbBtnz21ixXyGmyJLoyt.Hr2y5BdQj0ZUVNzXqWS_It1sYhl.qkFpm.7uB7498EWY eQvRXgh2vgICjoWrvS2PBrb3f3JdNnM6Qg7ylBsfb9VW_d5b7p3cW2xTQZN_344Ma5vLdRvpy5kG aAZR2ff1SgDwXOSLoz0VOoPmxLkKR4IrO4N9gvt92wb8feMdQOhXniKGyg64gqoaClTnPyHymEZ6 5asV4l87HJCt7uNmqzk2etfF.SVuWNc1c.HTPd9t6vnnzDGn3jaDXzikMmSZtH8kRmfQQvMS3l6S 9E0v_iPFdQta0Av964gpi0sWXG7z19FG0eYXa_Zu4HvzHljxbCrI-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Tue, 25 Feb 2020 16:56:02 +0000
Received: by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9e30ce8293df2f04dc4a561a7e50866f; Tue, 25 Feb 2020 16:56:00 +0000 (UTC)
To: sidrops@ietf.org
References: <20200224151532.GD19221@vurt.meerval.net> <20200224211531.GB60925@vurt.meerval.net> <20200225090338.10464b1a@glaurung.nlnetlabs.nl>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <9cc3a6a5-f9c8-23df-588e-48dee5db62d4@verizon.net>
Date: Tue, 25 Feb 2020 11:55:57 -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: <20200225090338.10464b1a@glaurung.nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
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/wdF6aFky1mksaeXduTo1Y5Mr6qU>
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: Tue, 25 Feb 2020 16:56:05 -0000

Martin,
> Job Snijders wrote:
>> Of course - in making strong statements like this one I can not afford
>> to assume I am right, so if you disagree - please tell me how I am
>> wrong (in detail :-) ).
> Let me counter with a different strong statement: In the context of
> RPKI, CRLs offer no additional value and can safely be ignored.
I disagree.
> The reason is the manifests. Unlike CRLs which only say "these
> certificates are not to be considered valid anymore", manifests say
> "this is the complete set of objects currently issued by this CA". They
> also refer to concrete objects, identifying them both by URI and a hash
> over their content. This is a much more powerful mechanism than CRLs.
As a co-author of the manifest document I can assure you that these 
objects are not intended as a replacement for CRLs. To provide analogous 
functionality one would have to interpret the absence of a cert from a 
Manifest as evidence that it was revoked, or expired. There is a lot of 
experience in the broader PKI community that suggests Subjects are 
sloppy about expiration dates for certs, and some evidence that CAs are 
not much better :-).
> What’s more, they offer a soft and a hard deadline for validity. Their
> next update field is a soft deadline, much like with CRLs. But there’s
> also a hard deadline in that the certificate they’ve been signed with
> expires eventually. While the former has the same ambiguity as the next
> update field of the CRL, the latter doesn’t. If the manifest is
> expired, the CA is basically gone.
I don't agree with the reasoning above. It's true that the cert used to 
verify (not sign) a Manifest will expire, but so will a CA cert. Why do 
you think that a CA will be better at maintaining a current Manifest vs. 
a current CRL? F or most RPKI CAs the trigger to generate a new Manifest 
will be the need to issue a new CRL (because many CAs have elected to 
issue CRLs on a daily basis).
> Further, the CRL is included in the manifest. So you can’t even replay
> an old CRL without also replaying the old manifest.
The discussion (in 6486) of what an RP should do when a current Manifest 
is not available, or when there are some discrepancies between what  the 
Manifest says and what has been retrieved allows for a lot of local 
policy discretion. As a result, an RP might well accept an old CRL and 
corresponding Manifest even though the Manifest appears to be stale.
> Essentially, no information conveyed by the CRL isn’t also conveyed by
> the manifest. The CRL solely serves to provide additional complexity
> for the code generating and validating RPKI objects and, apparently,
> creates ambiguity in the interpretation of the specification.

I disagree.

Steve