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

Louis Poinsignon <> Wed, 26 February 2020 02:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8DD3C3A08DC for <>; Tue, 25 Feb 2020 18:02:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.587
X-Spam-Status: No, score=0.587 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.663, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6hTQC2agW3Ck for <>; Tue, 25 Feb 2020 18:02:19 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6265F3A08D9 for <>; Tue, 25 Feb 2020 18:02:19 -0800 (PST)
Received: by with SMTP id r19so1143176ljg.3 for <>; Tue, 25 Feb 2020 18:02:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=OVn+h8Qhs0xrhn1g7HTj7LBNcdYRZkGk7fiw8g3OJ98=; b=UQRhckGj599/yogD3l1ganG+WdpWh1VHpRCBg+f0u3cx6f48ZWFk2AC6WCqBI+cMXe Znk9pyRNG5MRReVopSfPmxHUl37Bh6L/QjdunS8pORWlkG14TX2UUg/UFxuHiUFm//Ln LoyEjg1o+NWPxdsSw4Nh7zLYS0WtS/CVmv5nQKfo0RrmD74emiWvKOoCOYemmkr4YK3o rx4RgdSqeQXWyolQWJxsqdGH6JyNdGUyblrzCoKx6c4gKW2V88p7cMugjwvvIqpQqc+P jEnGLg+/mDztbdhiC8fNY/3ovTE2dwQZC2aqdO0s/6iP7PHYW70621u1E+NYBMMPvX1Y Jjcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=OVn+h8Qhs0xrhn1g7HTj7LBNcdYRZkGk7fiw8g3OJ98=; b=F1abQ/m+B5yTojuzV+FA6kcyR8bRoJDnJOS+nAwW5lzcTrnuYMpVkwsm+1vO31RN6t 7fxdXwikyTrA9XCjO7hqgKLFfe0/CW6SRz2yr3acjwemBQFXrf46TzQlvTyjx1KcEOw1 kJT2WOGyfidwCdoYf4uIN8wyO0wyilJBIOKxQKdM7YiahgaN+HOnPYOuxrvhydfyuQ3C zfkZhgxQGGr+eQTERJIUvlAV3A2hC2S1nqjtjgmuTitIpaoayqaxPWGbKUUFT9cBVifF azNBxg+UtZRtxNqucNcNufZbqlpW5ueJjG7+1jM2Tu5B1y+D4IEdR9b4UmFZBZdeaPGC JCOg==
X-Gm-Message-State: APjAAAWECxcDWEXD52aSk1cx8gPC9Qp6kp6TSYCkbJ5OhTazjYX8AcAO ayxlhbQaBGyt+YZY7AiRkRpCFBpJgu7eRj7sudsvQ7oa
X-Google-Smtp-Source: APXvYqxtApSEi0ghJ7/KjPS0XvW4tV7xi6ioIC+KUKWqxX66nx2HhdyU9UQt21EwU7SiABp7Oqd1EC6nN92Lq+NXcE0=
X-Received: by 2002:a2e:96c6:: with SMTP id d6mr1223634ljj.4.1582682536986; Tue, 25 Feb 2020 18:02:16 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Louis Poinsignon <>
Date: Tue, 25 Feb 2020 18:02:05 -0800
Message-ID: <>
Content-Type: multipart/alternative; boundary="00000000000068cb93059f70fed6"
Archived-At: <>
Subject: Re: [Sidrops] what to do when the CRL is hosed?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: A list for the SIDR Operations WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 26 Feb 2020 02:02:22 -0000

Hello all,
We're internally reviewing this with the crypto team which have more
experience maintaining PKIs.

My opinion on an operational standpoint.
I don't think I'd like having our routers suddenly reprocessing the million
routes associated with 78000 ROAs leaving us with an increased surface of
attack and potential reroutings. The outage lasted 8 hours as well.
Even with a replayed certificate, I don't believe the impact would be as
critical. And it would leave traces.
If the impact of a mistake is more punitive than a proper misuse, it's bad.

While I believe Job is right on the discrepancy between validators, I agree
with the point of Martin on the added complexity.

OctoRPKI is tolerant on absent/invalid CRLs. But it does check it against
certificates when valid.
Manifests are more sensitive.

Even though browsers and RPKI are different, I think we can learn from the
experience. Which is to get away from CRLs.

> Certificate Revocation Lists (CRLs) quickly became large, and contained
> mostly irrelevant data, so web browsers didn’t download them;
> The Online Certificate Status Protocol (OCSP) was unreliable, and so web
> browsers had to assume if it didn’t work that the website was still valid.

And lead to alternative solutions:

Looking into the data: is the
largest with 1MB and 22027 serials.
Most contain around 100-1000 serials and are a few KB.
The entirety of the 17127 CRLs is 70MB.

RPKI CA are already renewing, regenerating and distributing certificates
often. Why not reducing the maximum validity of certificates to one day?
This would relieve computing and storage as well as reducing the
importance/criticality of CRLs.

On Tue, 25 Feb 2020 at 15:51, Stephen Kent <stkent=> wrote:

> 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
> _______________________________________________
> Sidrops mailing list