Re: [Sidrops] proposed, revised text for Section 6

Stephen Kent <stkent@verizon.net> Tue, 05 May 2020 20:09 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 D30853A09D3 for <sidrops@ietfa.amsl.com>; Tue, 5 May 2020 13:09:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_MSPIKE_H2=-0.001, 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=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 FfdS6D-X0BnE for <sidrops@ietfa.amsl.com>; Tue, 5 May 2020 13:09:20 -0700 (PDT)
Received: from sonic304-10.consmr.mail.bf2.yahoo.com (sonic304-10.consmr.mail.bf2.yahoo.com [74.6.128.33]) (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 EF10A3A09CC for <sidrops@ietf.org>; Tue, 5 May 2020 13:09:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1588709358; bh=QfdJQRe1ltwRVx6DFp2ROS2aD8fEJVAzEDPMbAIKi50=; h=From:Subject:To:References:Date:In-Reply-To:From:Subject; b=ABGvYQy6B5rODx+zjnawFsMxKrAAygM4auG+QvlGmfEjetFdX/so87QR2fCBmIIwF4nvgvPcHnJNlsVwDwLeTRYgYVCfLX8Fa4cNNCuDzjp8ZIk2UOcHn6Y9H/Ev+dknE6ZO4Nf0Tj1/zZzAxpn/kZM3QLbX6e9c+AfTLtGvsy/TI1KMtsRtBEw20zCD/bu7nvXkU4R31gdv9/oOxOpu/K3vOzt1HHB5+/AzDxcW5u1fO60HOjXJ00yAiVD85HLHTgGgkn9YdsyJN2TOLxr7wqSFirI6WRqrtVAkNeI/yEqdj72YTBymdZ6qKh3KfnF7T/MIWt7EX+NBTnK+o+SAqg==
X-YMail-OSG: v3u.HlIVM1kupX340tyU3ZTzy8uPFyDwSMGkGd2gmFiRiHCC2rjbB7locnx0ZMZ yjNMbYAcyIu2XTRYIGuMsRCVoZMiwckv2Q_ArwKsIlnDcuV0b5iEI9kfsfhU0hMmGn5lRsofxUaC ztUNHQeuslgzY2bhhMiEue7znwTOwGWJXo.NosyuKtLzFODo3JBGY4vEMS83sjoE8m_3sf0quuoz NoNFhK6ArIyKicVx2ViclvbBuVajNxkukYRiZriGRXqeGy7I_cHEUqigjd8gaaGw9B4Em81C5j0N KD_.EdDfC2qmgHFUYGXrqNeZ_iHtNHPxE8q8oUwzPe9b0gBxpU99Hq2C24XeQXPXBFxjZM7cMAzw aol9kD8XGyLjAnDAN512KJPkipdB5uG9d4PLU8YNBNkWYsQwehhE3UwxlKNHVPbLaPxIFa2OTIMX 0Tjwj4TUM8yzd5m6MDROvfxl1RKPtaCJAsOzOv4MgVPxi3p.jZujN93HJ71NK707fj21rAqDfS97 Aq.Bo7SnQWep3usWO_my9iVdFJqOkzB_ZQDJzZlXxxmCZt0NSXLH.Vfsvbbxbczgd05ntt9B4OLo ciS.fBPY4wlje8gaFxCqM5qR7XppeO45.a0zDQVq09DiIN.jvBwFxV27mpsGAgd.Jo621dG74XzG efi.z2IqeXbNj7jvwUkEkDv06KnFe_XD8WJ3yQcOTvIPuaqGetCBe5mr7kNNTUDYuhjFWcyNLBvD y5OA2KbZi.fotHaFdAf9agnLIbHXJHI.A6dexQoyozqDl.QkW8p.8Mnr_nJnMnIAB91SdyL85kiu bz5f.1GozFKGb4KUDEB7PGfNmr.MckO94a0SaXp97jrUq7Xq1wpZhXMEGnz8jGbV5Kdih9dD5hxq 2TTQ0EpZwoMk_mOVGW1zABoEQ2s7rKQYctksROHD0XGl04yEQLkttdZ.nQgsRWl2CCOG8zYzGskU MghI9QqpvXMj0xm80Y7nxva3MZaBQkbA_H6.Z2NhXRZUvhO6ARjw47WHr7i4mjTaXFGQ49IQajJE Nrtz6ET6b0PiEJiUVVgfkSsAF5v3E9LQB9MxFfqxvNfPvYuRaK2VCYEoanKrDJuHPlBEWc75_Xjy rLK3U.jl1M1srURFAmpKQUiWCEvRpnFujI7kApnVYCzpl4n3q0w3ZKNO6ZwZ9IaUWId1LiFfI.NY 0CbeACZ0l5Txv8BoY8apOFAmuxG_37vJ4sVfrb.sYw9jkPFlOQgx_mqUJB4DhRGuJRdt45aV_jlk hWX3JzDlY4gWe6b8ahHr390OerVl7CjRV6aEQlS8k7jiNC24eIsxE.qSVcE47TktRmadb5kiuWUZ wl7crxXWBl6hiHNOsPACCfc5fXgy82c0swWeCIg6BLKds97aYr8FzCrvidnYIUXKph0GZG1N9sDp cIYNE3USOIxYRhWhmY9zt4XvUWAIKXWcZ5i2ThfXVVS39knuw_Jwchp8-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Tue, 5 May 2020 20:09:18 +0000
Received: by smtp411.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 1eaa3523c370bd50ab92f7dc853cbc25; Tue, 05 May 2020 20:09:13 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: sidrops@ietf.org
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <20200505121353.GB93200@vurt.meerval.net>
Message-ID: <526818da-c518-52d7-f9bf-799f1eb6637e@verizon.net>
Date: Tue, 5 May 2020 16:09:12 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0
MIME-Version: 1.0
In-Reply-To: <20200505121353.GB93200@vurt.meerval.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.15756 hermes Apache-HttpAsyncClient/4.1.4 (Java/11.0.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/6FmK30-O6gSA-zoSeucy5jEEcS8>
Subject: Re: [Sidrops] proposed, revised text for Section 6
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: Tue, 05 May 2020 20:09:23 -0000

Job,
> Small note: neither the archive
> (https://mailarchive.ietf.org/arch/msg/sidrops/Qy7YAVOUYrDVZxUPFPNZfekoJKI/)
> nor my mail client show any text in red. I am assuming the below quoted
> text replaces all of section 6 in RFC 6486. I added section numbers to
> the below quoted text and line-wrapped it. My comments are inline.
whoops. sorry about that. it was red when I sent it :-).
> Stephen, question for you: is the use of the word 'files' and 'objects'
> synonymous in the below text? Or are 'files' something different than
> 'objects'?
every object is represented by a file in the repository, so  the terms 
are equivalent in most cases on this document.
>> 6.1. Determining Manifest State & Object Acceptance
>>
>> For a given publication point, and given CA instance, an RP MUST
>> perform the following tests to determine the manifest state of the
>> publication point. (Note that, during CA key rollover [RFC6489],
>> signed objects for two or more different CA instances will appear at
>> the same publication point. The tests described below are to be
>> performed for a specified CA instance, i.e., a the manifest’s EE
>> certificate was issued by that CA.)
>>
>> 6.1.1. Select the CA's current manifest (the "current" manifest is the
>> manifest issued by this CA having the highest manifestNumber among all
>> valid manifests (as defined in Section 4.4). If the publication point
>> does not contain a valid manifest, proceed as described in Section
>> 6.2. (Lacking a valid manifest, the following tests cannot be
>> performed.)
>>
>> 6.1.2. Check that the current time (translated to UTC) is between
>> thisUpdate and nextUpdate. If the current time does not lie within
>> this interval, proceed as described in Section 6.4.
>>
>> 6.1.3. Acquire all objects at the publication point associated with
>> this CA instance, i.e., the CRL and each object containing an EE
>> certificate issued by the CA. If there are files listed in a manifest
>> that do not appear at the publication point, then proceed as described
>> Section 6.5.
>>
>> 6.1.4. Verify that the listed hash value of every file listed in the
>> manifest matches the value obtained by hashing the file at 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
>> proceed as described in Section 6.6.
>>
>> 6.1.5. If a current manifest contains entries for objects that are not
>> within the scope of the manifest, then the out-of-scope entries MUST
>> be disregarded in the context of this manifest.If there is no other
>> current manifest that describes these objects within that other
>> manifest's scope, then see Section 6.2.
>>
>> Note 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 manifest is revoked, the CA or publication point manager has
>> made an error. In this case all signed objects associated with the CA
>> instance MUST be ignored. Similarly, if the CRL for the CA instance is
>> not listed on a valid, current manifest, all signed objects associated
>> with the CA instance MUST be ignored, because the CRL is missing.
The original text didn't mark each step in the process as a sub-sub 
section, but your marking is a good strategy.
>> 6.2. Missing Manifests
>>
>> The absence of a current manifest at a publication point could occur
>> due to an error by the publisher or due to (malicious or accidental)
>> deletion or corruption of all valid manifests.
>>
>> When no valid manifest is available, there is no protection against
>> attacks that delete signed objects or replay old versions of signed
>> objects. To guard against the adverse impact of processing an
>> incomplete set of signed objects, an RP MUST treat all signed objects
>> associated with the missing manifest as invalid. (These objects are
>> all issued by the same instance of a CA.) RP software MUST issue a
>> warning when there is no current manifest for a CA instance.
>>
>> An RP may have access to a local cache containing a previously issued
>> manifest that is still valid. It is RECOMMENDED that the RP not make
>> use of this data, to ensure consistent a consistent outcome in when a
>> manifest is missing.
>>
>> 6.3. Invalid Manifests
>>
>> The presence of an invalid manifest at a publication point could occur
>> due to an error by the publisher or due to (malicious or accidental)
>> corruption of a valid manifest.An invalid manifest MUST never be used,
>> even if the manifestNumber of the invalid manifest is greater than
>> that of other (valid) manifests.
>> If there is no valid, current manifest available at the publication
>> point for the CA instance, an RP MUST treat the signed objects at the
>> publication point as indicated above in Section 6.2. A warning MUST be
>> issued when an invalid manifest is encountered.
>>
>> 6.4. Stale Manifests
>>
>> A manifest is considered stale if the current time is after the
>> nextUpdate time for the manifest.This could be due to publisher
>> failure to promptly publish a new manifest, or due to (malicious or
>> accidental) corruption or suppression of a more recent manifest.  All
>> signed objects at the publication point issued by the entity that has
>> published the stale manifest, and all descendant signed objects that
>> are validated using a certificate issued by the entity that has
>> published the stale manifest at this publication point, MUST be
>> treated at invalid and a warning MUST be issued.
>>
>> The primary risk in using such signed objects is that a newer manifest
>> exists that, if present, would indicate that certain objects have been
>> removed or replaced. (For example, the new manifest might show the
>> existence of a newer CRL and the removal of one or more revoked
>> certificates). Thus, the use of objects from a stale manifest may
>> cause an RP to incorrectly treat invalid objects as valid. The risk is
>> that the CRL covered by the stale manifest has been superseded, and
>> thus an RP will improperly treat a revoked certificate as valid.
>>
>> 6.5. Mismatch between Manifest and Publication Point
>>
>> If there exist valid signed objects associated with a CA instance and
>> they do not appear in any current, valid manifest for this CA
>> instance, these objects MUST be ignored by an RP, and a warning MUST
>> be issued.
> Are we sure about the above? The above approach would preclude us from
> using the current valid manifest to determine which .roa files should be
> deleted from the local system, right?
I'm not an implementer, but can't one delete cached roa files based on 
them not appearing in the current, valid manifest?
>> If there are files listed on the manifest that do not appear in the
>> repository, then these objects have been improperly deleted from
>> repository (via malice or accident). A primary purpose of manifests is
>> to detect such deletions. Therefore, in this case, an RP MUST ignore
>> all signed objects associated with this CA instance.
> A more robust approach might be to *not* ignore locally cached data (iff
> the locally cached data matches the filename and hash listed on the
> valid manifest, and a valid CRL is present)
Are you saying "IFF ALL of the missing files are present in the local 
cache, are not expired, and there is a valid CRL at the publication 
point, and it matches the file name and hash in the manifest, then we're 
OK to use the cached objects to fill in the missing files from the pub 
point? I think that's a reasonable exception. if others agree, I'll 
modify the text accordingly.
>> 6.6. Hash Values Not Matching Manifests
>>
>> A file appearing on a manifest with an incorrect hash value could
>> occur because of publisher error, but it also may indicate that an
>> attack has occurred, e.g., one in which an older version of an object
>> has been substituted for a newer version of the object. In this case
>> an RP cannot know the content of the missing object, and thus all
>> signed objects associated with this instance of the CA MUST be ignored
>> by the RP, and a warning MUST be issued.
> Same comment as in previous section: perhaps a more robust approach
> might be to *not* ignore locally cached data (iff the locally cached
> data matches the filename and hash listed on the valid manifest, and a
> valid CRL is present).

I think I agree with your analysis here too.

One final note, as I mentioned in my reply to George- the goal of 
consistent RP processing of RPKI data is more dependent on RPs having 
consistent caches on which to rely in the context of 6.5 and 6.6 processing.

Steve