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

Stephen Kent <stkent@verizon.net> Wed, 06 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 C63B73A0AFB for <sidrops@ietfa.amsl.com>; Wed, 6 May 2020 13:09:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.128
X-Spam-Level: *
X-Spam-Status: No, score=1.128 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, MANY_SPAN_IN_TEXT=3.227, 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 lQ46-mMQofCe for <sidrops@ietfa.amsl.com>; Wed, 6 May 2020 13:09:39 -0700 (PDT)
Received: from sonic305-3.consmr.mail.bf2.yahoo.com (sonic305-3.consmr.mail.bf2.yahoo.com [74.6.133.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 0FA1A3A0AFC for <sidrops@ietf.org>; Wed, 6 May 2020 13:09:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1588795777; bh=pA0F3bJSR1FmRUoaKRICf8wgYD3hnN4KaQyLmLOd6kU=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=c/HnWqYqBD13EUlLN1pZt0QC2D93spadefMiU1vKiV+A3m6vIfXMxrd4X9SA2VJeC/mAOYIrqm1zIECMs7WD6MBRsUF/UZRhCm+uI9PWGBvdf6eCZEZIGK3CsIQteMvgzXgnVygsrkbb/eSjFGUgCrqb9phaxNDLMjGyQ0yEAhe7yqt5ICKIekqxIlkFALu3Yr2OvTOa7qIy/nuY3V+fO3fPE+yehBPcDEyVQnb6DPrkyI+OCGDUOsABY53h/bhhf9+Ks5n7uo5XzWIn/RSyyG59Z9sf8WcSiMiYs31Y0ZQYjVuH6ifYqxBy2jOqSShfmxUBcHU5iaeuf3lWRN6dvg==
X-YMail-OSG: c9gc5fkVM1kNxvOqsMEEbmtzo2Ku1T_vL3ZicRnej4KRCILhKfueMqP1pwdSbbb J2mrw1x0JgUSpCpoXAFgQx88_sYKq7LWQwD6QvBd0Qtscgsun5.YGZG80mQ3VLTU915x9wPBifev Vte7xZypbsm_FIsPpI3QkOWWBOsCgWm_1tIMyTg3tKEjDLtkBh1EdhSG29hzgpYn7D6OY37nA7eb w3677rPAMPZHGXqVCSEXgUgZXIaVvcOI830vJeklhx5zHgKa0rhXQgDrIuJFyFyrXiiFiA_OLKTB 2RVJNTPVu4IfTxIxF2BVZrEIICG0F2KLKhPJMpLWEG02qLhZJXardZa._SWO10lKSqqb88ebaulI Pov0bWI7y1wJRfbZ0zQAEuAmAZ_yuE4GA7Wj_hPkiOgImhKDrASjERVheDmlBHs08EN35b.KKGT7 7ZBZwLFJNKs1zz5NqvIHAHru7VEwc0UuZZ6j.d0m89ItFTtNy21fDd0XRXv84ufOM4Rg1Tln9EvK WQW9Er8x39S6US2ZHldNaDl95z0OeOOR50bS0OhmopbOQayA8vXDNhkWCOASYuHAP6wk5Agm_OZU 3hwEeE_0ViDuvzKhTIBB4kPcv4cxnvlV_Ki2mn6OCdYTiu.NhreArNX9Uq_QKPtFbAEzPpVKaRwM XcuRvNbgnlQa_0l85n6m7XLderZv5QsElDmDRpg4tioBOUIS6aEos1htyNYhpd7bprvyUjMxRpuu Dzkvss2RW.gicnfsIjKllhvm6.V.QA.CfEWrpUOQyWc1IoEQQjZr_KCa0nIkK3cjLA671JloKW9c oUhK2tbzpgYRu3cRW2Yr0wRfTwlD5j5wItmstfCWlK2VFZfTYfpSKoPxOzz0qgJ_5sZ8reEw8sZ. XFRP8cl_RqeAFw35_L24_MfeEKM_25N7u4tTlH.iZ0CWYsjqQATapRCw6e073y8eVUuiIPz8JrzQ qpMvry60dZSKyaKyCkpJZT7e0gauC4SG1JdWs_zU5YfRn_yrVU0uScC4ZpiEB03Duqhpw3pkdtaI JPx.yEoAs8.QmVQXpQC.60tZ1MlP5B10205OWF9P9pPOjbh1HajrM8JYKgZPzswcIPoTRZsUeEfr gzeEBvj45tuW91NBvzEo3T6jnvp1K_ttBguD98FGp4YcDkZrSgLMbVNsZcedFRJdzM02MPk346S1 ZJWz5jXON9k34L0K.6ATF6YglvZY8aoRpLPJXBukBeMiTGyj0D57WQt30ey6WMlaRD44DbnqH9W4 goGZmg.RvynFG2jY8UYWveCvruoG5x7UfebPRhpBsUD62GtspqJSofwuq2xiiHYrkWmhwfZcQDlQ xk9dYgY7KAt18aEgAR5geyGb6JdteJpPcsy2B0r0PhOzQrhITozdhe6CBLobNbZERs72YUiSvw8n P4vnX.7P.lv6nrOTGEH7YCXLmWk0ygQA.vV_y65K1UHGSvnJfKJ0mEgZ_OGP3j278_2Kc.g--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Wed, 6 May 2020 20:09:37 +0000
Received: by smtp426.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 9ff6afda8069908ca9351e9048219e78; Wed, 06 May 2020 20:09:35 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: Oleg Muravskiy <oleg@ripe.net>
Cc: "sidrops@ietf.org" <sidrops@ietf.org>
References: <557f0928-c7b1-4b8d-b3b6-078733f7ef8a.ref@verizon.net> <557f0928-c7b1-4b8d-b3b6-078733f7ef8a@verizon.net> <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net>
Message-ID: <507640b8-30e7-9f95-e6ed-adba12efb090@verizon.net>
Date: Wed, 6 May 2020 16:09:34 -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: <1065C1CC-191A-4CFF-A87C-4F1CB165F303@ripe.net>
Content-Type: multipart/alternative; boundary="------------E1A38708AB64A22993D6A875"
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/weLE34HJ0Ndbggfk29i8XpMvAbU>
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: Wed, 06 May 2020 20:09:43 -0000

Oleg,
> Hi Steve,
>
> I have some comments inline:
I'm happy to see that your message shows the red highlighting I used.
>
>> On 4 May 2020, at 22:08, Stephen Kent 
>> <stkent=40verizon.net@dmarc.ietf.org 
>> <mailto:stkent=40verizon.net@dmarc.ietf.org>> wrote:
>>
>> 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.)
>>
>> 1.Selectthe CA's current manifest (the "current" manifest is the
>> manifest issued by this CAhaving the highest manifestNumber among
>> all valid manifests (as defined in Section 4.4).
>
> Without additional context (the discussion we've had here on the 
> list), it would not be clear for the reader where the possible 
> multiple candidates for the “current”  manifest come from. The CA 
> certificate contains a link (rsync URL) to a manifest, which is only 
> one file, so how could there be multiple options to “select” from? I 
> guess you refer to a possible use of a cache, or a difference between 
> contents of rsync and RRDP repositories?

I will revise the text to say that the processing starts with the 
manifest URL extracted from a CA cert, which should simplify matters. I 
was not trying to refer to a local cache or RRDP in the text above.

>
>> 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.)
>>
>> 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.
>>
>> 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 notappear at the publication point, then proceed as
>> describedSection 6.5.
>
> Wouldn’t we miss all the subordinate Resource Certificates if we only 
> look at objects containing an EE certificate?
> I think it would be enough if we say
>
> Acquire from this publication point all files listed in a manifest and 
> verify that they are issued by this CA instance.
Good point. I will reword the description of this processing step.
>
> Although it would be better to expand the “verify” part.
I will do so.
>
> Also, we should probably mention explicitly what the “publication 
> point” is (see my later remark about possible discrepancy between 
> different URLs from the CA cert).
  I did not mean to refer the the local cache above. I would like to 
describe this process in terms of the repository system model, as 
described in 6480, ignoring use of RRDP vs. rsync.
>
>> 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.
>
> The end of last sentence should have some duplicate words removed.
yep.
>
>>
>> 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 objectsassociated with a CA instanceand
>> they do not appear in any current, valid manifest for this CA instance,
>
> This should probably be the “the current, valid manifest”, not “any” 
> (as we only consider one manifest as the current in 6.1/1)?
agreed. a will change to "the current, valid manifest"
>
>> these objects MUST be ignored by an RP, and a warning MUST be issued.
>>
>> 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.
>>
>> 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.
>>
>>
>
>
> I wonder how far we should get with listing all possible 
> inconsistencies in this document, but from my developer’s perspective 
> I think  we should list as much as possible, if we want RP software to 
> behave in the same way.
agreed.  I will try to address the inconsistencies you noted; feel free 
to suggest others.
>
> Going through what we described in RFC8488, one of such 
> inconsistencies is when manifest contains more than one CRL entry.
RFC 8488 talks only about the requirement to omit the optional CRL filed 
in the generic CMS format we adopted. It does not address the issue you 
mention here, i.e., what if the manifest includes more than one CRL. 
But, I agree that there does not appear to be an explicit prohibition of 
having more than one CRL enumerated in a manifest. We should say this 
explicitly. Next question: what do we do if we encounter more than one?
> Another is when the manifest is not in the publication point of a CA 
> certificate. There are two distinct links from the CA certificate – 
> one to the publication point, and one to the manifest.
yes, and 6487 does not say that the manifest must be in the directory 
specified by the pub point URI (id-ad-caRepository) Maybe we should 
revise 6487 to make that a requirement. I can address that here as well.
> Technically, the manifest link could contain different directory than 
> a publication point link. If you discover a manifest by following the 
> manifest link, and follow the rules applied above, using the link from 
> the CA cert (and not the location of the manifest), you would not 
> catch this discrepancy.
> Also note  that similar discrepancy could exist with the CRL location 
> (as it also has its own link from the cert), but that one is covered 
> by the new text above.

yes, 6487 does not require the CRLDP to point to a file in the pub point 
specified by the id-ad-caRepository URL in the CA cert. Again, how about 
a revision to 6487 to clarify this? It would make life simpler.

Steve