Re: [Sidrops] 6486bis: Failed Fetches

Stephen Kent <stkent@verizon.net> Mon, 17 August 2020 18:34 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 A0EFC3A0927 for <sidrops@ietfa.amsl.com>; Mon, 17 Aug 2020 11:34:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.05
X-Spam-Level:
X-Spam-Status: No, score=-3.05 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, NICE_REPLY_A=-0.949, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 rLAYnjW6DUcn for <sidrops@ietfa.amsl.com>; Mon, 17 Aug 2020 11:34:26 -0700 (PDT)
Received: from sonic314-14.consmr.mail.bf2.yahoo.com (sonic314-14.consmr.mail.bf2.yahoo.com [74.6.132.124]) (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 B58573A090B for <sidrops@ietf.org>; Mon, 17 Aug 2020 11:34:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1597689264; bh=oJ2AECXYQl31f6AUJMnPN6jODQIsOteMcw6YEK7dYS0=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=uAbr+m1YKtWuG+y5lN1nZJwQ70KSqYn457W4kcAgsRckOCqkFpZaiZ9RZDkctoz5b31z8Zgn9nTUw0xpapKVJGVKM8p76kdQM5KDOyu6aOoAqDRws7RIKXT5YtFGI39hLSkirug26tzkcBL5wRN3WZs6feikk0cs5/3iOo6rHRHe54+DMfGjU3CH05ON1W4QyG7C8qm25v5pp0s8MC9TWi5lsaU3CrCbg3EKVfp/QaZX6pMROyvtStgCASmziuc572hUpjF+IQf0T3+duqEoH+uZuSvgUw+Gxl7ynd/Zyekt0K9eMJUHdQl9669kn9tYk5dWrYdEs+Md6bjbnKn4Iw==
X-YMail-OSG: _ssm404VM1nsBejokvbyDYr09iP49W3yAf7QnbL52uYLOVDArRy6xkqJYKEVNEV swmjqwVleP1ehf_gtZ.Yrr7bLDzuRk6BU8kES9B8KuY7z3Y9jPZPXZMnocLD0Vwn2bT35EZxAZTb k3EenTZuKyW9jnDrIcvkDdbTApgn_wsqx80VN.jgIC3zMOIKHjDpFvMWNKfNI2qxBP2C5xwCLkR6 Y35kIcAe4BnruhOomFgrtNtaHig1NroInDNkT_eKClYcYy62S73sng3Sqlw8p2fp.WUhmbbHV9AZ 2yMNplEDV8RT0120A_Tuwiw79SMckPFpIzhnb3kMrgDDMMn8ogK8pwUAd2krkDI1bbRjzgOVelNX rAGLvOcdE0mF4GmHmKJSckOyKGM2htoAJbglimRu5tm.7LcaqAUvKnH2wG5p2sXTMurIacxyCoAS _IJBPyBInsAXVok0hopgsrjBuRCQIDlGKaObMrDNZDZHDCVBheOzsTkYdNcsRltu2ysRwcJWpnrH xKW.gj7aZV9gg0A4U_vz73ybZVGj1xvP4n3brH45eC21bN5NZbrqTSro9_KIScRdocFT2dZAvz2B NBhWQtrhloacfCnhjAxqtYiAgmmzxlYYNNAf9r9MEIYbmFzCGHonVXEGh5MCoLMxGUlG5GzRtqYN LgBSa1TBWMUhpsgkSmW8XAX6QynDRpmnQoeWKogTHdB6NsZTYhel14ovqNUvRuFYw6t8veyeaawb oBEtLr_Jy1Hje8vrnsQ66CntMXnkUq8z6TsShmjyrzr7JHGNOEx2IJKcrX_tp.xx5V_UeNYD9r5c og77_v_rrrHh0WfOf6obtum3J0tB_hVnNUDF70fTq3wIw5zjXHnSkmK5FX9i1.Lt7Bokg7oIrtJM gisZNGAxHLpPWNvW6K2RJ_R_YHOXYvPwQiLgwd9GImCzkFLCg2XALZDDqrNcIiWE7FTi8vXREbYY X.KqpZSiko.8uCkwwFVA8b.7ggKcjVSFONH1btNtLfKZ3V6hfsA.p9w3k4E8_16EV_3bAd9JEDyQ z6uJDXHvzDF5fAjPQ16OarCdH8twxwKz20YVjjqm5Fme52z2BFSsttuUHV5mPpkiMWlxRyAZ54Ay JBwYFbmf_0MYQ867YRJBqcJe4CcQ_tOMPJRiHvxCZwHtFHGE_3qonxvNXaY23zzifzP_y2oSEL7J V_cLvynDJmvONw_qv_D1yhtEYzTOTUNBWhMVH5Uw264e2iTPRik0ODnvqmhkJ0sbOm8M5zugIbpn FIoWCvq87e_2sqEpKX11WHpiu21_AF_SSBVUqNJn7DmFMeOjPKz2F7FJbdrfF0BOx9IqvJbv6VIm Cj2n8V.26LkSxwc5RvOQkB1fI63zkf5tlmVyG8bp1lQhzWfWKpKODs43QUSAzFKs1v8P3yUvyvkH EZ1k1rn6aB4h1nhPZYpd7P3fGgseMqYhG34XynBFVsBPL4Yrx_VZCErICpujr_eD9Few-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.bf2.yahoo.com with HTTP; Mon, 17 Aug 2020 18:34:24 +0000
Received: by smtp404.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID fa610df0fcfbdeca2064b56940f30946; Mon, 17 Aug 2020 18:34:21 +0000 (UTC)
To: sidrops@ietf.org
References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl>
From: Stephen Kent <stkent@verizon.net>
Message-ID: <c1a8fffb-9106-d08e-4254-44ddf1a0115a@verizon.net>
Date: Mon, 17 Aug 2020 14:34:20 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0
MIME-Version: 1.0
In-Reply-To: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Mailer: WebService/1.1.16455 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Apache-HttpAsyncClient/4.1.4 (Java/11.0.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/QKQbO0LwmrInhqaVYodcIHclrs0>
Subject: Re: [Sidrops] 6486bis: Failed Fetches
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: Mon, 17 Aug 2020 18:34:28 -0000

Martin,
> Heisann,
>
> I started to implement the rules laid out in section 6 "Relying
> Party Processing of Manifests" of the draft and now have a few
> questions and remarks. I decided to split these up into separate
> messages. So, expect a few more messages ...
>
>                               *   *   *
>
> It is not quite clear how to deal with failed fetches.

The overall response to a failed fetch is described in the intro to 
Section 6, as well as in 6.7. the intro states:

    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.  ...

Section 6.7 reiterates this description of what to do, and provide more 
details re what "termination of processing" means.

> Section
> 6.4 dictates that invalid signed objects (but curiously not invalid
> certificates or CRLs) fail a fetch. The consequence of this is that a
> fetch already fails if a single ROA (or worse: a single ghost-buster
> record) is expired.

Section 6.4 deals with acquiring all files referenced by a manifest, 
including certs and CRLs. The text says:

    The RP MUST acquire all of the files enumerated in the manifest
    (fileList) from the publication point.  This includes the CRL, each
    object containing an EE certificate issued by the CA, and any
    subordinate CA and EE certificates.

> Section 6.7 now states that I should keep using "cached versions of the
> objects associated with this CA instance." What does that actually
> mean? What are these objects associated with the instance? The objects
> listed on the new manifest or the old manifest? Or does objects here
> mean validated output generated earlier?

The phrase "CA instance" is used throughout Section 6 to accommodate CA 
key or alg rollover. So, a CA instance refers to a CA cert and the 
objects issued under it, as indicated by the SIA info. This is described 
in Section 6.1, which notes to use the id-ad-rpkiManifest URI, as well 
as in the intro to Section 6.

The cached versions of objects refers to certs, CRLs, and signed objects 
that were validated during a previous fetch cycle, and which are not 
stale/expired.

> If indeed it means RPKI objects, then doesn’t the expired ROA
> essentially block all updates to the other objects to the CA? That
> would strike me as counter-productive in terms of robustness.
Are you positing the case where the cache contains an expired ROA for a 
CA instance, and a fetch that would have replaced the expired ROA fails? 
In that case, the cache entry for that ROA would no longer be valid, but 
I don;'t think that would affect other cache entries for the CA 
instance. Yes, this re-write of 6486 trades off robustness for more 
restrictive manifest checking.
> This rule also blocks skipping objects of types I don’t know or care
> about. I will have to at least do signed object validation on them,
> which means reading and parsing them and then do signature validation.
> If that is intended, I think this should be called out explicitly in
> the document.
If a manifest points to objects that are not CRLs, certs, ROAs, etc., 
then it is in error. But, your question seems to be what processing has 
to be performed on the files contained in an apparently valid manifest, 
right? Section 6.4 and RFC 6488 defines the tests to be performed, and 
6.4 explicitly cites 6488. What additional info do you feel is needed here?
> But I’m not even sure it provides any benefit. I, say, I am validating
> a resource tagged association (RTA, [0]), I don’t care about the ROAs
> at all. Does the RTA become invalid because a CA somewhere in the
> validation chain had an expired ROA?

I have not examined the RTA ID, and it's an expired draft, so ...

Steve