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

Job Snijders <job@ntt.net> Mon, 24 February 2020 20:55 UTC

Return-Path: <job@instituut.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 4FE753A12FC for <sidrops@ietfa.amsl.com>; Mon, 24 Feb 2020 12:55:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.647
X-Spam-Level:
X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 sLMUvPyLTiZ7 for <sidrops@ietfa.amsl.com>; Mon, 24 Feb 2020 12:55:26 -0800 (PST)
Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) (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 E52BC3A12F9 for <sidrops@ietf.org>; Mon, 24 Feb 2020 12:55:25 -0800 (PST)
Received: by mail-wr1-f44.google.com with SMTP id l5so7822908wrx.4 for <sidrops@ietf.org>; Mon, 24 Feb 2020 12:55:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=rruVFHpx6zIYcOjcwoSH7jNxVvfuZj4ABzFYR1GrtTU=; b=T8ziFdB9K0R208LpxrUpwQMOV2/gNoqTRu6l9ZFxKnYnl+yzLrPFmCI6du2ta0lcU9 FGaCMYAmDqs79Le97hX12hyplbDxHVXcx7wP04+CeedVDM7Dm19pLfiqU/zkXTqXAXia Nx4/geuh2/6SWRfVQVbGU+NlBwc++SIsimpFpwVAouTUreiJ2dg5LO3H+5kZcxeCzNL5 3hyQL6m4GSeoisIimKZotv4+F9srWMrz3Luokm6MqD4FnVTWQqBj+LtC1DwqWLzl8oOb nDKB2Gl8mN/Zf3J7d+sOX7GIloFILR+b/w7gQrsqGEFCA2RYX9Wzh4IOt4NiEQ4tsn7L Qk0A==
X-Gm-Message-State: APjAAAWTLm0viahIm5qqMn9gJoof+rs9EVLvxLN09bYgmdMIpXJpf/d2 ePWGng3cJ8PZT0iYNy0AZuDCZg==
X-Google-Smtp-Source: APXvYqyDc3+Benj6eai/XaoX5OA4uFi4e9wqNHQuGrtlA08PjnnE1KWiz1GUzC75RMhwJ/asgD6g6g==
X-Received: by 2002:adf:a4c1:: with SMTP id h1mr70208552wrb.10.1582577723507; Mon, 24 Feb 2020 12:55:23 -0800 (PST)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id q14sm20827629wrj.81.2020.02.24.12.55.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Feb 2020 12:55:22 -0800 (PST)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 91448005; Mon, 24 Feb 2020 20:55:21 +0000 (UTC)
Date: Mon, 24 Feb 2020 20:55:21 +0000
From: Job Snijders <job@ntt.net>
To: Claudio Jeker <claudio@openbsd.org>
Cc: sidrops@ietf.org
Message-ID: <20200224205521.GA60925@vurt.meerval.net>
References: <20200224151532.GD19221@vurt.meerval.net> <20200224154449.GB86633@diehard.n-r-g.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200224154449.GB86633@diehard.n-r-g.com>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/xwsit9SffiOSkuwa-7Mq5IoXYLw>
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: Mon, 24 Feb 2020 20:55:27 -0000

Thanks claudio

(forwarding this back to the list, seems claudio's mail for some reason
didn't show up in the archives)

On Mon, Feb 24, 2020 at 04:44:49PM +0100, Claudio Jeker wrote:
> On Mon, Feb 24, 2020 at 03:15:32PM +0000, Job Snijders wrote:
> > Hi group,
> > 
> > It seems we need guidance and consensus on what to do when the CRL is
> > hosed in some way or shape. We have two implementation discrepancies pop
> > up recently:
> > 
> > https://github.com/NLnetLabs/routinator/issues/274
> > RIPE NCC's top level CRL expired this weekend
> > (https://www.ripe.net/support/service-announcements/rpki-infrastructure-issues) 
> > 
> > https://lists.nlnetlabs.nl/pipermail/rpki/2019-December/000109.html
> > 
> > OpenBSD's rpki-client uses the x509 certificate validation functions
> > that come from libressl, which doesn't have a button to turn off only CRL
> > timestamp verification. I was told that some nasty code would be
> > required to work around that, so one can argue that rolling things by
> > hand in X509 handling rarely is a great idea.
> > 
> > One could also argue that a softer landing is needed, unavailability of
> > the CRL should mean that only the CRL itself is not available and
> > proceed to validate the tree without the revocation list. I can see how
> > that is helpful in some circumstances.
> > 
> > So, what to do? Whatever it is, ideally all validators follow a similar
> > process.
> 
> The process at the moment is clear: the embedded X509 certificates
> reference a CRL and so the validator has to check if that certificate was
> revoked via the CRL. This verification needs to follow the procedure of
> X509 certificate validation (which includes timestamp verification).
> If you want a soft landing then please just remove the CRL from the
> system.
> 
> In general it is important that the timestamps in the various RPKI objects
> are checked during verification. Not doing so will put you at risk for
> replay attacks.
> 
> -- 
> :wq Claudio