Re: [Sidrops] trying to limit RP processing variability

Job Snijders <job@ntt.net> Wed, 15 April 2020 14:00 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 AABE03A089B for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 07:00:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.65
X-Spam-Level:
X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=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 OK9l11gyHVHH for <sidrops@ietfa.amsl.com>; Wed, 15 Apr 2020 07:00:18 -0700 (PDT)
Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) (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 395EF3A0899 for <sidrops@ietf.org>; Wed, 15 Apr 2020 07:00:16 -0700 (PDT)
Received: by mail-wr1-f42.google.com with SMTP id d17so12386664wrg.11 for <sidrops@ietf.org>; Wed, 15 Apr 2020 07:00:16 -0700 (PDT)
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:content-transfer-encoding :in-reply-to; bh=QUXziKiUfckCLwSJbvhBwUqrd/rCQJnuTOMg9xtlW/M=; b=rhUEkU6OGhQJrVXx/Phnix85mw0xQIO7z3ADt+gvn4QuzCL7AVwR4Q0Rue+fxhlBYb XRcvSpTAfZbDhjHXS6YGdBPtrEdjVmYI1EnbYnRx3U3Xmno0CCmcDamsLIN0/TEkfig3 SuI9/7QzGqeU7LOzFKmwNTogCje2ZD+s1tCkD9s+u93tyM9IhY3F+zvjUWMT1xF0h/OM V6o0i+vEBjg5FXvM2Dv35NpdPjFYWQ2q/uvDH3Dr026v+n6nm+4ZjPaosVrv3AxYuyXO y7NGuefek3ivIqFUuzVK80L+cNpZxuddiNG04YA9YqnjqRqclgWGuCOkRpRbvvuMDy+g TZOA==
X-Gm-Message-State: AGi0PuY3nxwrg0nuThm6wM+Bc//dRoPOm1C5VHmD50EhEygEAxfXgySB 5ZkM7p4k6Y2A0SXjfJp1PuoHMg==
X-Google-Smtp-Source: APiQypK5cNbnu71b8ETNh9lWNnB+gNS+IxOyhT4cr7sOnvTxKBkIcEqR+0bK+7Q5mNwv+TvRwH9KZQ==
X-Received: by 2002:adf:ca0c:: with SMTP id o12mr8482197wrh.306.1586959214851; Wed, 15 Apr 2020 07:00:14 -0700 (PDT)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id w3sm4911213wrc.18.2020.04.15.07.00.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Apr 2020 07:00:13 -0700 (PDT)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id a5862a81; Wed, 15 Apr 2020 14:00:12 +0000 (UTC)
Date: Wed, 15 Apr 2020 14:00:12 +0000
From: Job Snijders <job@ntt.net>
To: Martin Hoffmann <martin@opennetlabs.com>
Cc: Stephen Kent <stkent=40verizon.net@dmarc.ietf.org>, "sidrops@ietf.org" <sidrops@ietf.org>
Message-ID: <20200415140012.GB30412@vurt.meerval.net>
References: <a9448e54-320f-300c-d4f9-d01aca2b6ef4.ref@verizon.net> <a9448e54-320f-300c-d4f9-d01aca2b6ef4@verizon.net> <20200415150141.016d021d@glaurung.nlnetlabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20200415150141.016d021d@glaurung.nlnetlabs.nl>
X-Clacks-Overhead: GNU Terry Pratchett
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/46fXDCMsPYLwSAzhlJwVVa41PtU>
Subject: Re: [Sidrops] trying to limit RP processing variability
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, 15 Apr 2020 14:00:20 -0000

Dear Martin,

On Wed, Apr 15, 2020 at 03:01:41PM +0200, Martin Hoffmann wrote:
> > Missing: an object named in a Manifest, but not available for
> > download from a PP, is termed *missing*. An RP has no obvious way to
> > acquire missing objects, but operators SHOULD be warned about which
> > objects are missing.
> 
> Since "missing" seems to be the opposite of the "present" in the case
> overview below, I think we need to more precisely define the meaning
> for both manifests and CRLs.
> 
> I would define the meaning of "manifest missing": the manifest
> referenced in the CA certificate is not available for download from a
> PP. That leads to the case where there is a valid manifest at the PP
> but it is not the one on the CA certificate.
> 
> "CRL missing" is a little more complicated, since there is two places
> where CRLs are referenced: in the manifest and in the EE certificates
> of signed objects. So we also have the case where a CRL in an EE
> certificate isn’t actually mentioned in the manifest.
> 
> > *Case analysis*
> [...] 
> > 
> > Below is a proposed outline for the cases. The group needs to decide 
> > what action is to be taken in each case.
> 
> To get that discussion started, here’s my proposals for these cases (in
> line with what I argued earlier).
> 
> > 1.Manifest present, valid, current
> 
> If there is a present, valid, and current manifest, the CRL can safely
> be ignored for all objects.

I'd like to ask you for some clarification, Stephen Kent listed 4
different cases, I parapharsed here:

1.1. Manifest present, valid, current AND CRL present, valid, current
1.2. Manifest present, valid, current AND CRL present, stale
1.3. Manifest present, valid, current AND CRL present, invalid
1.4. Manifest present, valid, current AND CRL missing

When you say "can safely be ignored", do you mean, MAY be ignored,
SHOULD be ignored? or MUST be ignored? In all four cases?

> In order to avoid using partial sets of information, the entire
> content of the PP is ignored if any object is missing, corrupted, or
> invalid.

It appears we are inching towards consensus on avoiding to use partial
sets, I think that's good news.

> Presumably this chould only be limited to objects of the same type,
> i.e., if there is a least one missing, corrupted, or invalid ROA,
> discard all ROAs.
> 
> If the aim is to avoid risking accidentally marking routes as invalid,
> this should probably also extend to all information published by child
> CAs.

Yes.

Kind regards,

Job