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

Job Snijders <job@ntt.net> Mon, 24 February 2020 21:15 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 BBE793A134E for <sidrops@ietfa.amsl.com>; Mon, 24 Feb 2020 13:15:37 -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 kBJV5h7QvAjI for <sidrops@ietfa.amsl.com>; Mon, 24 Feb 2020 13:15:36 -0800 (PST)
Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (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 48D233A134D for <sidrops@ietf.org>; Mon, 24 Feb 2020 13:15:35 -0800 (PST)
Received: by mail-wr1-f49.google.com with SMTP id g4so5788419wro.13 for <sidrops@ietf.org>; Mon, 24 Feb 2020 13:15:35 -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:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=OMGEdBQjjA+PcTnuvg8Mo+GkX1UanJDWW3xV0Cgcb0I=; b=NAuCspgt8NIlXelxCnHg1g517bmCc2kNKklZfLJPwb0COTlNYKtS/zpK7xOmzFHPES hPqQ/R4mbLuHCGHgLzOtoIo6QhW/AS5/CUsGedUICwgIAlGXDpAMm4cP1uF1x39mQ43d kFmbVWf9rHtsoAnCg36+VNL0XIcG98awgj82yrpCFTE2Lx9a0iMnXUextfCbvigLhlJq ISWqbotKrAuEyAP2Y0TDJka8PpSB2icKgw1wwEv2T5hq5+3m8NsP1sf8A994CXod3u6K /o4xd91NrkYsrMb0K+lv0xGW/rkZlguZlwNj35WFc0T4GanPC2MPUiRSkYL6ThAVOFCM woyA==
X-Gm-Message-State: APjAAAV+faL12Luc6ahawQeiZvKxLC/mZGR+X5CNwRm3T1MXiDI6pF49 t5LVqjg/80i5NePLu0M3DH29iLjkULQ=
X-Google-Smtp-Source: APXvYqzv36wuqyIWBOG2T2Yby90Euy3j2Ii+DVP4/4WLrUhLbm7Nrf/BLn1Ozvuapu6C33orUiFkbg==
X-Received: by 2002:adf:e3cd:: with SMTP id k13mr44403667wrm.302.1582578933673; Mon, 24 Feb 2020 13:15:33 -0800 (PST)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id b10sm856387wmj.48.2020.02.24.13.15.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 Feb 2020 13:15:32 -0800 (PST)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id a3fd9f25; Mon, 24 Feb 2020 21:15:31 +0000 (UTC)
Date: Mon, 24 Feb 2020 21:15:31 +0000
From: Job Snijders <job@ntt.net>
To: sidrops@ietf.org, claudio@openbsd.org
Message-ID: <20200224211531.GB60925@vurt.meerval.net>
References: <20200224151532.GD19221@vurt.meerval.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200224151532.GD19221@vurt.meerval.net>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/BKbYujWcr4qWJOahFoBqgZHrFX8>
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 21:15:38 -0000

To reply myself: 

In case the CRL expired, or is otherwise somehow invalid; and the cache
validator continues to consider the entire validation tree to be valid
for some purpose, the validator is vulnerable to replay attacks because
the use of unencrypted transport such as rsync (which supported in all
validators, by mandate) give no support to trust anything anymore.  I
think ignoring the CRLs state goes against the entire RPKI trust-model
mindset.

A cache validator MUST consider the certificate have been appeared on
the Certificate Revocation List (CRL) issued by the CA represented by
certificate if the CRL is expired.

While one can argue in different contexts of the application of X509
technology different (more forgiving) policies can apply; in the use
case of RPKI I think we cannot tolerate anything less than to assume the
CA has failed when the CRL is inaccessible or expired. And those running
CA's will want to take careful note of this critical operational aspect.

Cache validator implementations which didn't stop parsing RIPE NCC's
tree today, should be aware they are have a security issue and consider
how to upgrade their validation strategy. I think OpenBSD's rpki-client
was the only one to get it right today.

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 :-) ).

Kind regards,

Job


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.
> 
> Kind regards,
> 
> Job