Re: [Sidrops] 6486bis: referenced object validation

George Michaelson <ggm@algebras.org> Fri, 04 December 2020 01:33 UTC

Return-Path: <ggm@algebras.org>
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 B41503A11F8 for <sidrops@ietfa.amsl.com>; Thu, 3 Dec 2020 17:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=algebras-org.20150623.gappssmtp.com
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 ikj4oubB4AQ8 for <sidrops@ietfa.amsl.com>; Thu, 3 Dec 2020 17:33:51 -0800 (PST)
Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (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 BF0583A11F5 for <sidrops@ietf.org>; Thu, 3 Dec 2020 17:33:50 -0800 (PST)
Received: by mail-lf1-x130.google.com with SMTP id u18so5510611lfd.9 for <sidrops@ietf.org>; Thu, 03 Dec 2020 17:33:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=algebras-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=byvP8QiFDft+5Rg7Sz+TOaPfB+IdafMQqMSFr3dGTNw=; b=oybmnmGWJ+NlrhvUL+rziGNoOSqFAcNBKblCjseagJM5nJ4pLA33e+0HwVfyk1gtnb FuM5coBWGQrrLB1SlPwEwb3MO/xtc51/Jw68Q3cFL9YOG3RHR09qQYtjmhDNo3jOA1zB OQj09IAutYQR08Q3Ggr8tmOJWM80DiKPXw689RBD1sFEvKUPYl0XtFTy/+VGf2aUmMCz skWfkI9Bv7jyd3IziNDK4ZrW//BVGgmd3smdRKfyf0phr5MtPLxpnYmKini73BGyGbCv 1cGnOA1ykSxC7P4Zn5e4oyQhcyxhFdtNdZYdxb4/tq8vXrkUMF6qvBuMVTz7iI+HeWpG yqhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=byvP8QiFDft+5Rg7Sz+TOaPfB+IdafMQqMSFr3dGTNw=; b=OJ5Z1Hc5KWmaL8nT7gpppfd0/FJNIyuMGexXFwTxV+I1327Stx5voqAFbUClXxKKvT k2s6Cl7tPTo4iEri2jB2ViaUlZcF7ovAuAEvppYL35nQoCIHTEf8/5vqNF56eWDVMYaf Iwsqk8HGo/i3cPTxrYpeWTCtfbiLKNmWAkFoEJmiuU9/T9pCEae/av5mey0WkgbZ9yKe WeU+5TCLkrsWJggq0ffHalFTRkI7j4Ga5oVaBnemRpkVmHypRn4JltuAUCvRNxLHJDWs CT9K8+sNi7XJaLq5oPsfUjWARDL6xwz8lfKppz4qt48pB/hmLXruideKqCb15FN2UoJr 8zNw==
X-Gm-Message-State: AOAM532LPfXzQvsNCe4OqqfdZYZv+AtsrQxpLTSNN/tFj5rdhwOuvB9a 5i3Rq6bsS9Gecid5a5V1p6hcItg1mkY9veybLM86q8XB6F4=
X-Google-Smtp-Source: ABdhPJxtLAIRg0SPzg/fM6tFOkzoHVX/FzVprcVPhTbO4au4BmheiMPaFWY6I6B4BAPYh2HMzgzDp5wNLOGJPqOdHOg=
X-Received: by 2002:ac2:4834:: with SMTP id 20mr2340735lft.598.1607045628046; Thu, 03 Dec 2020 17:33:48 -0800 (PST)
MIME-Version: 1.0
References: <20201203224213.gnb2nawujxm7a32q@benm-laptop>
In-Reply-To: <20201203224213.gnb2nawujxm7a32q@benm-laptop>
From: George Michaelson <ggm@algebras.org>
Date: Fri, 04 Dec 2020 11:33:37 +1000
Message-ID: <CAKr6gn0C7311d8jRHcpxe=VAthY_e_jzt_7xv_kdnnqW242Y6g@mail.gmail.com>
To: Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
Cc: SIDR Operations WG <sidrops@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/JPfIhiBbbfNiDJgDyOAmkCjH168>
Subject: Re: [Sidrops] 6486bis: referenced object validation
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: Fri, 04 Dec 2020 01:33:54 -0000

I support this kind of change to the wording.

I believe this language addresses my concern with rejection of a
Manifest which was legal before an expiry timer, and becomes illegal
purely because of the expiry of a descendent child CA.

The signing chain over the Manifest itself, its EE, and the CA chain
over that EE still need to be valid, unexpired, unrevoked.

Validation of objects on the Manifest, validity of the manifest given
other errors, are not altered in this change.

cheers

-G

On Fri, Dec 4, 2020 at 8:42 AM Ben Maddison
<benm=40workonline.africa@dmarc.ietf.org> wrote:
>
> Hi all,
>
> As a result of the incident last night that caused the number of VRPs
> output by some RPs (certainly routinator, possibly others too) to drop
> dramatically, a couple of us have been going over the observed behaviour
> in comparison with the current text of 6486-bis.
>
> It appears from Job's analysis [1] that the incident was triggered when
> several resource certs that were listed on an APNIC issued manifest
> became invalid due to their 'notAfter' time expiring, which in turn
> caused the affected RPs to consider the manifest invalid and fail the
> fetch.
>
> It should be perfectly legitimate for a manifest to list objects which
> will become invalid during the lifetime of the manifest, or which are
> not yet valid when the manifest is generated (for pre-staging).
> The presence of such objects should not invalidate the manifest.
>
> I think there are at least two places that need an update in light of
> this:
>
> Section 6.4 states:
>     """
>     If there are files listed in
>     the manifest that cannot be retrieved from the publication point, or
>     if they fail the validity tests specified in [RFC6488], the fetch has
>     failed and the RP MUST proceed to Section 6.7
>     """
>
> The reference should probably be to both RFC6487 and RFC6488, as the
> former provides the validation details for .cer and .crl objects, which
> are presumably intended to be included in this step.
>
> Additionally, due to the values in the 'notBefore' and 'notAfter' in a
> Resource of EE cert, an object that was legitimately included in a
> manifest may become invalid when processed later in the manifests
> lifetime by an RP.
>
> I would therefore suggest the following revision:
>     """
>     ... if they fail the validity tests specified in [RFC6487] and [RFC6488],
>     with the exception of the checks against certificate Validity From
>     and To values described in Section 7.2 of [RFC6487], the fetch has
>     failed ...
>     """
>
> Although not directly related to the current problem, the list of
> objects in section 6.4 for which the ability to process is mandatory
> should perhaps be reduced to those in general circulation today, and not
> include BGPsec certs or ghostbuster records, since those add
> approximately zero utility to an operator who wishes to run an RP today,
> and are therefore unlikely to be priorities for implementation.
>
> Next, section 6.6 states:
>     """
>     If a current manifest contains entries for objects that are not
>     within the scope of the manifest (Section 6.2), the fetch has failed
>     and the RP SHOULD proceed to Section 6.7
>     """
> I believe that the reference to 6.2 is a typo, and should point to
> section 2:
>     """
>     A manifest associated with a CA's repository publication point
>     contains a list of:
>     o  the set of (non-expired, non-revoked) certificates issued and
>        published by this CA,
>     o  the most recent CRL issued by this CA, and
>     o  all published signed objects that are verifiable using EE
>        certificates [RFC6487] issued by this CA.
>     """
>
> The term "non-expired" begs the question of whether a certificate should
> be non-expired at the time of manifest generation or RP processing to be
> in scope.
>
> On the one hand, insisting that a listed certificate be valid throughout the manifest
> lifetime is what gave rise to the failure described above, and is
> clearly, IMO, the wrong choice.
>
> On the other, insisting that a certificate be valid at the time of
> manifest generation precludes certificates which have not yet reached
> their notBefore time. Validating as if "at manifest generation" also
> appears to contravene the guidance in section 4.6.1 of RFC6487:
>     """
>     Relying Parties SHOULD NOT attempt to infer from this
>     time information that a certificate was valid at a time in the past,
>     or that it will be valid at a time in the future, as the scope of an
>     RP's test of validity of a certificate refers specifically to
>     validity at the current time.
>     """
>
> As above, therefore, I would suggest that rather than choosing either
> of the above options, the question of temporal expiry should be left
> out of manifest validation altogether.
> Thus point one of section 2 becomes:
>     """
>     A manifest associated with a CA's repository publication point
>     contains a list of:
>     o  the set of non-revoked certificates issued and published by
>        this CA,
>     o  the most recent CRL issued by this CA, and
>     o  all published signed objects that are verifiable using EE
>        certificates [RFC6487] issued by this CA.
>
>     The list MUST include any objects that have a validity period that
>     overlaps the period between the thisUpdate and nextUpdate times of
>     the manifest.
>
>     ...
>     """
>
> There may be other parts of the text that are similarly in need of
> update or clarification on this point: I'll update if I find any.
>
> Hopefully the above makes sense. Please let me know if anything is
> unclear.
>
> Cheers,
>
> Ben
>
> [1]: https://lists.nlnetlabs.nl/pipermail/rpki/2020-December/000245.html
> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops