Re: [Sidrops] revised text for section 6 of 6486bis

Stephen Kent <stkent@verizon.net> Wed, 23 December 2020 16:41 UTC

Return-Path: <stkent@verizon.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 7AD373A0C36 for <sidrops@ietfa.amsl.com>; Wed, 23 Dec 2020 08:41:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.007
X-Spam-Level:
X-Spam-Status: No, score=-2.007 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, HTML_MESSAGE=0.001, HTML_OBFUSCATE_10_20=0.093, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net
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 cmQSLbTcZMFv for <sidrops@ietfa.amsl.com>; Wed, 23 Dec 2020 08:41:28 -0800 (PST)
Received: from sonic314-13.consmr.mail.bf2.yahoo.com (sonic314-13.consmr.mail.bf2.yahoo.com [74.6.132.123]) (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 D6E3A3A0BFF for <sidrops@ietf.org>; Wed, 23 Dec 2020 08:41:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1608741686; bh=moC4S0dyZhVXK6G0SZAPTCstZv+0WWsPO9k3vPtVEuk=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=g8tACHXcul1gKsHUobilByCNKqhktfb6A40iiQuxWxgl0Jpqph6bSbXOdx3/xU40RvKciFKXZuapIMHM157BdNtY6FX2utoaqQSN8dkj4kIAMFNcKO9+r7X7pcDWMyvK/CFrszU0cEcFbVLZ7TF2nZhPKo27IkCv/W8ZiqKFfTQJ5tFjD70XtYKZfBZNq4byP094hQ6RWhfQwskDMhDxqixvXWOcAqgTqnuX8Qs8ugTU8F8FNBe7sPyHZe4pHhGfaBOm4HFySBE9tMLl0foUmMoeSBMZvfOTsYhFr83hc4K0M6d16j57YlPaBe8vYLTjYdFHzc9rr2Yx8AouDPP81g==
X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1608741686; bh=jaHMqZNShxITDOxsxZX3hbxBaxg6cNAZwAnC4d2NnfR=; h=Subject:To:From:Date:From:Subject; b=ovkjhD+FrzqaDidpY6mUD5HM4BguXvcTQfJa5MAgPVM0WQn52Y4rvb+5f6OmpN11xX0UP9Sn+nLWALUVy+mAaKD4dqxQk9mKgYwF5h1CpHcxNM5gYiJ+6BOTSb0Er3ajVKflQYhIVW+ajcOmrI7x8SF0/lsQBt/dXSJEH23JMfg79Ae8L0QrHibyoHtJRMVBbmo2pyLloPTtM9ZpuZWsS2DmMu6kbcdDWPdcsoI3q86xpCADHpFmgGc1/PR4Tg82BIonA2yFzG5SWQw29R1wxWbpG6vr69wTJ3nK3dtdBO8cNQ0Psk7K0yZ1ZCCfz8+naYabXxl9dia+7N51mANcDw==
X-YMail-OSG: 7gwRcQUVM1nndAQ2gsD_q6iX9UCtzxKZihZ6oGG0JEGQdXaTbQcxyeoIi96L.N0 .taJs1KYkGW7.QWLHMtdMrIElflkOv2PoJGkejw_iyIPWGQCmNR9ELJOwwSueNT8psyo2Zw7DMhh WiGc6TWYLswxWkKiGxC_RJrQBP3WgQduYpzWoKQBdmGCpqw1xMQpJ33SAFVwkzhi8hLiEUTVzCk7 gLXYPpiwGy5YQsm1HqOckIjNspYoexnohwXDUZWwpQtdLzjnAON6MVYi8Wud_to_1Am58A_Yz7Nx 0jYOD7qnXlPYDjjfGxTkaEjcbJyAlr6rTSeLMuJDzrmbgKzgri.6cVJBTunvcwVCyT1mo.3Jb3vC iGuDNJbEuSFwkeKm3ATaeV_xRENjajPrtgRvbNsETmaDL75dbZR2MwhxuizF5eQt5YlHGJTAKJ.. KQDAjD9MGu7_pbDCHd36v8DePyUBun0dv3Cd6IlhXOp4M0PrpeOvre7_OcF_eWzt1bHV5PkMVU07 znDvZCtofEuXvlllHMFDS.n2kkRWVZl2HSgI3cfoeB3sgefG0ogazstPke6IqKjqrwdu5Mz_rg9q WKEWXV3scxHUqGsqcS.9tzqLdoeqNCfuKwCUa8X_Drom1lnF_vBm2AeJG8o8HhXOh.Ic6w2vpYZe 4hs.OWVEdl1nJ9IQuAOS_lfXH2e3TQmk3eR0HEaSB1FzFFmOcjoyfl4k7FnCdUQfjL2exJS7AjgV nF9w0lqAvIlF.gZ1J1DCqihSwiDAcTAEBELZxHQLIg.8Nwkgkr64JrnEE8DfsUF43Cv7mg2My1t5 BxqeoYkAulEcVYL_eYqAjns3XDsNbdoIm8NyIvDuKo4kd1IxqBamQhI3R1tjV.e8vY988yGASbOn VlxtJbKydSeHLxsBI7luW1stfg0sTonIKQbCTirWbTvBDdPSZPsJ7XQh03BdFmknileqDOX2X.FL fjKHQ2_1UaFgYHqO9PeLvXEkZhBGdaFwe7jHZYVsV4kK4XJjTC20DBqO5NvSvk25Uo6o6V7Ohq0j PG2WRnkrEA5Qyhes5epRxyaDLvBqoKOHnXzol.egOHpNroukouaKExRGlQw_7wUMYSaKWgIAvpWr V4lY2OvYruMFGqcNRQf7iuqmgVHJXpmqErKcJmld6G_tl4fe88fUS0q6.ewd4R9KV9gtp6o2iLbx 5_ajPwT.drfncyh5DguDOuLBiSFItdYDuLeu8zvRU4zaa.YfbGyWwwavNiaM4yWNpgx29m5CtcGF CYTwvTI7iXBFW740EghdhLA.PilYNa3fzN6rJgaOrWmpcpvfS.XoiPz_i12G_r7RVEuvdGgubkN4 w6kCjDcuTL9W84LrA1I0KMavQb_NwwvUzHgf3xLfygUl9x0SixX2hSGmMWq00_Ro4A.hiM30V9FB xEiu8.u7O.Ew0L22BKn7IZ0e3lXeJrP_zL83zPwD26KzJzYFGcK.otuMp1F8m9mCKP5g91_QdCBr Xwb6HwqIKztcX4_0WGQ37qWYAH5iZeBSavHhzPqyw.HEE_iR.uY5sPiv7WlmcJifdu1nD1pWypPG .wjSXjbgjwXeHe8s2lfCMIPoGoZV5N1lLufgIbGdk_FCAasNlGEAUlf8m0HrmCi3fcSBIwkd3UzT PMBuyMdKIMda.KS0QvstnwNB3Sd849.oecFlnoSxWZxVMsdqM1yTaSeTW0ybIo60z6UFJJrI.whk s9WRlPoHLij3b0ptIYu3BRQofz2fsVzyNlczW8hOqA2f6bZTBfW9WgkLISNSUC7m726fPb4ZTL86 r9qzt6C.c5f53z6QLh93FFjwl71uKZL_A0EqERHiDvzsxYhESs2kvcd35YGfT50Bm9ENM.kYeCLt GItYBVFj1fnDvxAcsu4tk2MX9GFIRyFH67L3zZPeBCDNOFoaG6eaC8Bfz1Vrb8_eVBTuDqynj757 yLxGh4psV2bmpwxd5vQfy7QS74UXk5ERuM1SZnMcHsjp1X0iLvDeHe67tD54le24er.dgac_vDtH l0HFIVmudSqyRGpmlPKMpLd7f5QwYetI07pZQATddpFuSsmwh.tO.Pm28RLD48JENHLgsif.kmIO UNU829HaOmAMWSkMXk_VwZRi10LRgeOKzi_smVovNhnWvw2D385sCEsK50.tC86wIw8KfX93ha5a 5_OvAqVecfYxFl2u5UjC5avj_dK9_K183q7nEfqpNCeTM1AtTrCL2SS4Ed_wL3T4eM6nXwiobjdX z0SKGZ0vQTgHSQN9HI7aJpuvZOuWEwcl2iD82nK_Nc2t1WrB.YNL7rFOB8HUoAJuhaNZdi8Y9a4c qnNRytABjlQ7f8Fr_3mgKGs5qF6zFLjQfSm7xgvAN5u0SFISi02T68iELoq26Rv9Q4gV.Vj43zSN afFOTIIZU2zBzkMIuOFyssbmKporqqzZicVo3BsV0yW4_D2vUpS1Tzl6dcv28Y1hB62Tn1iu9fK_ QgBbsbQ4E
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Wed, 23 Dec 2020 16:41:26 +0000
Received: by smtp415.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f21bf2fef6d2d6956d9f79c29cf9768a; Wed, 23 Dec 2020 16:41:21 +0000 (UTC)
To: sidrops@ietf.org
References: <12001c46-2fe3-6616-2969-f97d247e972e.ref@verizon.net> <12001c46-2fe3-6616-2969-f97d247e972e@verizon.net> <BF0F19FB-DBB5-4A68-9146-DDE27243A969@ripe.net>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <877cb93a-2715-b608-9cbd-01b4a89a04db@verizon.net>
Date: Wed, 23 Dec 2020 11:41:20 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <BF0F19FB-DBB5-4A68-9146-DDE27243A969@ripe.net>
Content-Type: multipart/alternative; boundary="------------DF63A1DFAFF9D02A168E7BC8"
Content-Language: en-US
X-Mailer: WebService/1.1.17278 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/zlyB0o04ZPVMtlMDTKBX_2_x1gI>
Subject: Re: [Sidrops] revised text for section 6 of 6486bis
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, 23 Dec 2020 16:41:31 -0000

Ties,

You make a good point. The text in 6.6 is a hold over from previous 
revisions. It does go against the notion of using the manifest only to 
ensure that the files retrieved by an RP are the same as the ones 
published by the relevant CA. So, I have removed that text as shown below.

Removing the requirement to verify that the retrieve files match the 
manifest scope will not be a concern if we can identify other RPKI RFCs 
that require the RP to perform all of the same checks. The scope of a 
manifest is defined in Section 2 of 8486 as:

 ��� 1. the set of (non-expired, non-revoked) certificates issued and 
published by this CA,

 �� 2. the most recent CRL issued by this CA, and

 �� 3. all published signed objects that are verifiable using EE 
certificates [RFC6487] issued by this CA

The cert validation described in 6487 should ensure that all of the 
certs encountered are not revoked and not expired, so #1 is satisfied 
elsewhere. Similarly, 6487 requires an RP to check that is has acquired 
a current CRL, although is does not address the issue of having 
encountered multiple CRL files as part of a fetch. That still seems to 
be an area where some additional clarification of behavior is needed.

It is not clear that #3 above is addressed in other RFCs. If a ROA is 
missing, because the CA failed to publish it, it's not clear which other 
PKIX RFC will cause an RP to detect this. Similarly, if a subordinate CA 
cert is missing from the pub point, and the manifest, it's not clear how 
an RP will detect this (possibly erroneous) omission by the CA. The 
simple requirement that what is retrieved is what was published will 
have been met, but this still allows several forms of CA errors to go 
undetected by an RP.

Steve

-----


6.Relying Party Processing of Manifests

Each RP must determine which signed objects it will use for
validating assertions about INRs and their use (e.g., which ROAs to
use in the construction of route filters).As noted earlier,
manifests are designed to allow an RP to detect manipulation of
repository data, errors by a CA or repository manager, and/or active
attacks on the communication channel between an RP and a repository.
Unless all of the files enumerated in a manifest can be obtained by
an RP during a fetch operation, the fetch is considered to have
failed and the RP MUST retry the fetch later.

[RFC6480] suggests (but does not mandate) that the RPKI model employ
fetches that are incremental, e.g., an RP transfers files from a
publication point only if they are new/changed since the previous,
successful, fetch represented in the RP's local cache.This document
avoids language that relies on details of the underlying file
transfer mechanism employed by an RP and a publication point to
effect this operation.Thus the term "fetch" refers to an operation
that attempts to acquire the full set of files at a publication
point, consistent with the id-ad-rpkiManifest URI extracted from a CA
certificate's SIA (see below).

If a fetch fails, it is assumed that a subsequent fetch will resolve
problems encountered during the fetch.Until such time as a
successful fetch is executed, an RP SHOULD use cached data from a
previous, successful fetch.This response is intended to prevent an
RP from misinterpreting data associated with a publication point, and
thus possibly treating invalid routes as valid, or vice versa.

The processing described below is designed to cause all RPs with
access to the same local cache and RPKI repository data to acquire
the same set of validated repository files. It does not ensure that
the RPs will achieve the same results with regard to validation of
RPKI data, since that depends on how each RP resolves any conflicts
that may arise in processing the retrieved files. Moreover, in
operation, different RPs will access repositories at different times,
and some RPs may experience local cache failures, so there is no
guarantee that all RPs will achieve the same results with regard to
acquisition or validation of RPKI data.

Note also that there is a "chicken and egg" relationship between the
manifest and the CRL for a given CA instance.If the EE certificate
for the current manifest is revoked, i.e., it appears in the current
CRL, then the CA or publication point manager has made a serious
error.In this case the fetch has failed; proceed to Section 6.6.
Similarly, if the CRL is not listed on a valid, current manifest,
acquired during a fetch, the fetch has failed; proceed to
Section 6.6, because the CRL is considered missing.

6.1.Manifest Processing Overview

For a given publication point, an RP MUST perform a series of tests
to determine which signed object files at the publication point are
acceptable.The tests described below (Section 6.2 to Section 6.5)
are to be performed using the manifest identified by the id-ad-
rpkiManifest URI extracted from a CA certificate's SIA.All of the
files referenced by the manifest MUST be located at the
publication point specified by the id-ad-caRepository URI from the
(same) CA certificate's SIA.The manifest and the files it
references MUST reside at the same publication point.If an RP
encounters any files that appear on a manifest but do not reside at
the same publication point as the manifest the RP MUST treat the
fetch as failed, and a warning MUST be issued (see Section 6.6
below).

Note that, during CA key rollover [RFC6489], signed objects for two
or more different CA instances will appear at the same publication
point.Manifest processing is to be performed separately for each CA
instance, guided by the SIA id-ad-rpkiManifest URI in each CA
certificate.

6.2.Acquiring a Manifest for a CA

The RP MUST fetch the manifest identified by the SIA id-ad-
rpkiManifest URI in the CA certificate.If an RP cannot retrieve a
manifest using this URI, or if the manifest is not valid
(Section 4.4), an RP MUST treat this as a failed fetch and, proceed
to Section 6.6; otherwise proceed to Section 6.3.

6.3.Detecting Stale and or Prematurely-issued Manifests

The RP MUST check that the current time (translated to UTC) is
between thisUpdate and nextUpdate.If the current time lies within
this interval, proceed to Section 6.4.If the current time is
earlier than thisUpdate, the CA has made an error; this is a failed
fetch and the RP MUST proceed to Section 6.6.If the current time is
later than nextUpdate, then the manifest is stale; this is a failed
fetch and RP MUST proceed to Section 6.6; otherwise proceed to
Section 6.4.

6.4.Acquiring Files Referenced by a Manifest

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.6; otherwise,
proceed to Section 6.5

6.5.Matching File Names and Hashes

The RP MUST verify that the hash value of each file listed in the
manifest matches the value obtained by hashing the file acquired from
the publication point.If the computed hash value of a file listed
on the manifest does not match the hash value contained in the
manifest, then the fetch has failed and the RP MUST proceed to
Section 6.6; otherwise he fetch isdeemed successful and the RP will
 � process the fetched objects.

6.6.Failed Fetches

If a fetch fails for any of the reasons cited in 6.2-6.6, the RP MUST
issue a warning indicating the reason(s)for termination of processing
with regard to this CA instance.It is RECOMMENDED that a human
operator be notified of this warning.

Termination of processing means that the RP SHOULD continue to use
cached versions of the objects associated with this CA instance,
until such time as they become stale or they can be replaced by
objects from a successful fetch.This implies that the RP MUST not
try to acquire and validate subordinate signed objects, e.g.,
subordinate CA certificates, until the next interval when the RP is
scheduled to fetch and process data for this CA instance.