Re: [Sidrops] 6486bis: referenced object validation

Tim Bruijnzeels <tim@nlnetlabs.nl> Fri, 18 December 2020 08:28 UTC

Return-Path: <tim@nlnetlabs.nl>
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 74B803A1160 for <sidrops@ietfa.amsl.com>; Fri, 18 Dec 2020 00:28:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nlnetlabs.nl
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 Hp_NXAdHTZCP for <sidrops@ietfa.amsl.com>; Fri, 18 Dec 2020 00:28:15 -0800 (PST)
Received: from outbound.soverin.net (outbound.soverin.net [IPv6:2a01:4f8:fff0:2d:8::215]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5ED3A115E for <sidrops@ietf.org>; Fri, 18 Dec 2020 00:28:14 -0800 (PST)
Received: from smtp.soverin.net (unknown [10.10.3.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 5AC7760845; Fri, 18 Dec 2020 08:28:12 +0000 (UTC)
Received: from smtp.soverin.net (smtp.soverin.net [159.69.232.138]) by soverin.net
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nlnetlabs.nl; s=soverin; t=1608280091; bh=knisq2iOJuZtfpfJA80QyKYcS4ElBEv2umDtGm0PT9o=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=YuUhIi9/TFxJiaDx4pMqZpE07DlfGhNKrnDkIy1ZPzLlxSc9anBhW8bDOi+as5pSE zeVaVO6NkwVhKMeFKYieSOI0x66C5SAr2N4XG1qZGAJnLKtCog+pOpzaED3b1AyL9I u/7td4afLtTEO6vI3JQkK/rIiYkfortuxwAKhEtKlcwQCMYMcoBrgQ/PhHGt2bOynH P+q7be6uyyls1+YfG/vn8aM5T7fojLhTu8UbSRxEYUMl3xYcQZqgEW3henBMNZmhIO d3J+bPHqt6+CNZ5RLlLsQ7jB42VNL+vlQlDhXgCWdrrQYasi7puNBFbKQuJprZO6z4 7mY8f6dpAZM0Q==
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Tim Bruijnzeels <tim@nlnetlabs.nl>
In-Reply-To: <X8qowhjq+3iKpiAN@bench.sobornost.net>
Date: Fri, 18 Dec 2020 09:28:03 +0100
Cc: Benno Overeinder <benno@nlnetlabs.nl>, SIDR Operations WG <sidrops@ietf.org>, Martin Hoffmann <martin@opennetlabs.com>, Ben Maddison <benm=40workonline.africa@dmarc.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3FA0BE3-ACB5-47AD-BFC9-D7FE46197672@nlnetlabs.nl>
References: <20201203224213.gnb2nawujxm7a32q@benm-laptop> <20201204111651.4e865d7d@glaurung.nlnetlabs.nl> <X8oSBlR1pDhX83nH@bench.sobornost.net> <62CCDADA-E2B5-4354-82E5-995837633307@nlnetlabs.nl> <X8on7A4R63HYUnpz@bench.sobornost.net> <d518f9de-850c-ad10-49a5-1eee4c85fa6b@NLnetLabs.nl> <X8pJoTEUDwpE6iIi@bench.sobornost.net> <953B1447-1253-4EA2-A805-5DAB9CD394D6@nlnetlabs.nl> <X8qowhjq+3iKpiAN@bench.sobornost.net>
To: Job Snijders <job@ntt.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/bI3NEbhzihELFd2VHyfIe813F9I>
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, 18 Dec 2020 08:28:17 -0000

Dear group,

> On 4 Dec 2020, at 22:23, Job Snijders <job@ntt.net> wrote:
> 
> Dear group,
> 
> On Fri, Dec 04, 2020 at 04:58:02PM +0100, Tim Bruijnzeels wrote:
>> On 6486 in particular there was a strong desire communicated by
>> operators that RPs behave the *same* way.
> 
>> Which is why we were hesitant to implement the changes suggested by
>> you in the GH issue. 
> 
> I have a celebratory moment to share with all of you, below is a
> terminal transcript and some hashes which will allow you to confirm my
> findings.
> 
> <snip/>

In summary: rpki-client, fort and routinator now follow the same approach. I believe it's being adopted by octo and the ripe ncc validator as well. I am not sure about rpstir and rcynic.

This begs the question whether we should seek to reword the -bis text to essentially just insist that all current objects on a manifest should be present and accounted for, instead of the more complicated text that it has now which has resulted in at least two cases where all objects under an RIR were rejected - if implemented. It will come as no surprise, that I for one would welcome that change.

Let me quote Martin's motivation and suggestion in Reply to Ben's email earlier in this thread:

> On 4 Dec 2020, at 11:16, Martin Hoffmann <martin@opennetlabs.com> wrote:
> 
> Ben Maddison wrote:
>> 
>> 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 the incident shows a general flaw in the approach that
> anything being wrong with any of the objects published by the CA
> should lead to all the CA’s objects being invalidated: It prohibits a
> CA from publishing invalid objects on purpose.
> 
> The validity time is only one such case. Another one that we already
> know about is changing resource entitlements in the CA certificate.
> This case is actually worse since the CA itself has no influence on
> this happening and, as the protocols are now, there is no automated
> way of agreeing on a timeline for the process.
> 
> It is not entirely unlikely that we will encounter more such issues in
> the future.
> 
> So perhaps instead of trying to work around each of these issues as
> they arise, we should go back and look at what started this revision in
> the first place. That was an observation that by manipulating a
> publication point’s objects, an attacker can force a route announcement
> to become RPKI invalid.
> 
> The current approach does solve this problem but it also attempts to
> solve a different problem: to protect a CA from accidentally publishing
> invalid data. But as we found out, that requires anticipating the
> intentions of a CA. Perhaps it is better to trust a CA and accept that
> if it fails there will be problems for its resources.
> 
> Under this approach, the manifest expresses which objects the CA
> intended to publish. If all the objects listed on the manifest are
> present with a matching hash, the publication point reflects the intent
> of the CA and can be processed. If it contains invalid objects, these
> can be discarded individually.
> 
> This approach will be simpler and easier to implement. It will avoid
> the invalidation of the entire CA because of expired or not yet valid
> CA certificates or changing resource entitlements. It may, however,
> lead to a partial set of objects applying to a particular resource.
> That may be intentional or by accident. Whether it is better to reject
> the partial set accepting that an intentionally partial set is rejected
> or to accept an accidental partial set to be included depends on the
> particular application of RPKI. For ROV, rejecting the set may be
> better (although there are consequences of that, too) whereas for
> router keys or Ghostbuster records including it would seem to be fine.
> 
> In other words, the proposal is to simplify the text for section 6.4
> to say:
> 
>      The RP MUST acquire all of the files enumerated in the manifest
>      (fileList) from the publication point.  If there are files listed
>      in the manifest that cannot be retrieved from the publication
>      point the fetch has failed and the RP MUST proceed to Section 6.7;
>      otherwise, proceed to Section 6.5.
> 
> In addition, section 6.6 can be repurposed to specify the behaviour in
> case of invalid objects. As a proposal:
> 
>   6.6. Invalid Files
> 
>      If files listed in on the manifest fail the validity tests
>      specified in [RFC6487] and [RFC6488], the fetch has not
>      necessarily failed. However, applications of the RPKI may define
>      specific consequences if one or more files are invalid.
> 
> Alternatively, this section can provide the rules for existing
> applications of the RPKI, i.e., ROV, BGPsec, and GBR as well as
> delegation to child CAs.
> 
> I understand that this proposal is a departure from our current
> approach, but I would like to ask the working group to consider it
> nonetheless as it keeps validation relatively simple and, by separating
> out the individual steps of the overall process, should limit the
> number of unforeseen consequences.
> 
> Kind regards,
> Martin





> _______________________________________________
> Sidrops mailing list
> Sidrops@ietf.org
> https://www.ietf.org/mailman/listinfo/sidrops