Re: [Sidrops] 6486bis: Failed Fetches

Stephen Kent <stkent@verizon.net> Fri, 21 August 2020 18:45 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 485793A0DAF for <sidrops@ietfa.amsl.com>; Fri, 21 Aug 2020 11:45:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.049
X-Spam-Level:
X-Spam-Status: No, score=-3.049 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, 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 IxfM2MGOHd_Y for <sidrops@ietfa.amsl.com>; Fri, 21 Aug 2020 11:45:00 -0700 (PDT)
Received: from sonic310-14.consmr.mail.bf2.yahoo.com (sonic310-14.consmr.mail.bf2.yahoo.com [74.6.135.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 0B1533A0DAE for <sidrops@ietf.org>; Fri, 21 Aug 2020 11:44:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1598035498; bh=a8GPCSmA2qt52MlKmcSqZKORx5mk1mz6DzT68YDmkf8=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=V5GLcK6Q0oMCR2iZg5RsnIV2QwPP9AfIpcVOSm0yA0BUAq9dT/+hJI+o7/ovuhTxkioEURiM9G5ZswJ2q6M0dNqVGFmkTg9JNsToDfhT2Pa0z9FksfwYX8gP6LwxSowx70dZcrobzP2M/Y4XKJbw+7096xRaOAoewvZuRK8JcW8p+7KIWGwpTnaViaHQwVT3O1BMZyO7qHS0isBz/4pTEal/0eZVDavZ0wdp76oFwICF3J+W4s34NBH1YN9aIAh2rCoVxHyc3Fbkh4M1Pd/0YMyMS6WF3VVqclozmwU2Tk2Seo5zhZQ599yqroZ6ejU+nprdC5GefwpxhSq0eVHHxw==
X-YMail-OSG: oI8T8QoVM1kN3Gnqqz.X8jI.6CsvBmm.u8q9FNWrkfG7BWip6fGjUyptcR8Hu1Z xvBvlX8XGsel0O.ES1OrDdD7_3P_24ugu0JPVdycBS.5eMzKuakaLsrvGBXAc_sTLCmhI1W6zBid vDQZoQlwdXe.9BDrkQvtxIdWEV0C637eEbFszFMlQTdIUIoh8VGXaQQ_qY5..cqFGW.lMYVOcKtg _iZieRDE0A2ed8eoUuvz1ASS82Ca0S1h8ZIlqkwkWyD2c9jDj97hhFZ3vH10K3sEh_fmXylItN7Z 6fd_nsnAusmeVGDJXGCNI_4q6GM4K4ZGWkWzLsIWCQjPUqCnwwn50GxUgVKGzFzcNxdaNXfUZCuS hrAjDLmbB3IZ6T4G4e0we0tIQVEP4blZNxxkI.nfFYA_BuTS7mzRovrP1_FEHSPYVQ4kofmOvYto 10DgAYtmYPZKHjJJg9rDDRKX0zkNy9cXCP_4MCl9dMhcz.Abv9XECJeYgIveACTPjGA4Wj8LhbAF ESsxucx7Fy289RbPhaiKIpkIwCX7pFmgl6JgWsty5AWYiW3x3QCfObz8XpY0jUf2sNuI5yStFfUN O4Cn9uzJSnw3j8BiC8oOTEKXhrxoJPjSgDMXtczdtdrIpPT.IssIxZhMZdAzWEn_TYTd84ft.b2Y NYcpOF.fBvfjAPkhqPj9x1Tz0cQE02t6BQieUiYJQJ1CssWXX_udtMZ80mJpJzdpKcNqATs46TNj s6oATP6HAN.4TRRC07liOTPvEKb2_3TB0bLO_i.kznndWMngNGYWC8IdKtXkxe4CFRFfQa66Yq7J HLFzm6MD99YqQRvzxL_WMst.I5ABXcVlKt8sLH8JAdn4FBFLtVb0jd9gcOJgsUoru0QKhIA0uDDZ al2BjLJx.C.XcYvHkJVTiduQr4iCeaXv0L3iwvGL53gY5ATtOBlpXOO18cQQu8mNuShLFeTNwjqn sXttSJPU.2CsZBZUNzphj9.zIjdp8_I2S8XlSebsOVpaMVVG9TB3wToW1kLzAgefF1QEPJimryjI cNrstVezRQnmhIdEx7M7RmApf1jBgB_Xi1Idy9FIMy32Bo8BiN9YjQktoLtU2z9hMDJTmafeVpe5 CBLkJgB.xJe8Ywixrt8kKwoTdpAuWNPnSgP84mfLufaWPt18903CPC27m8FFPDp8mJCc4PG57tp3 i3L3mdEE1qwB.TOtHwU8_AAZT40KQ4SxdDl8Aem_TajWGLToYaSl.qwz5WKI57xpyIPvzzaUSGP7 Mx8YdkUqMa0Mfb4ufZ0LFIgGg4TZbSDDAcEL8Fb_C9wZcuSBJz9_Qln3Xno4uFvRtT3c9bqLPeQW qC48zkCLerlFVhauLdQeC.5leRWgU8segZgOuEFV.MtupGYsaxtV5bfL37GmvFddkApOKtvTbK3N EurSNE1Z.gCo7D449Esm6nNK7_BKzCmgbxRY.TCSKQKHiG3qgOAhlr9taia08FylcyD4YokMOZJs CkPSoF.8uEd_ImhZkYCsrn2ywctaOhHB37eS5yVc3EVNuOVUEtdABnLh0knxWP816Z5bRO1BBROU 7O87t1jSWh5xmWpsjK.nC8dkXASPqW9kDAFJyVYi_5pgQGWDm_A--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Fri, 21 Aug 2020 18:44:58 +0000
Received: by smtp424.mail.bf1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b66873e2a54a97bca25158ab62bdac0b; Fri, 21 Aug 2020 18:44:57 +0000 (UTC)
From: Stephen Kent <stkent@verizon.net>
To: George Michaelson <ggm@algebras.org>, Martin Hoffmann <martin@opennetlabs.com>
Cc: SIDR Operations WG <sidrops@ietf.org>
References: <20200817163134.29aa1a6b@glaurung.nlnetlabs.nl> <c1a8fffb-9106-d08e-4254-44ddf1a0115a@verizon.net> <20200818083659.1922a98c@grisu.home.partim.org> <CAKr6gn2Ai0jM+ZPE86Nnw-Y4p7qnoY4Ce2TKqVDde5R0aC4-zw@mail.gmail.com>
Message-ID: <4d2396bd-0fc0-b19c-546d-7d63a2966003@verizon.net>
Date: Fri, 21 Aug 2020 14:44:55 -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: <CAKr6gn2Ai0jM+ZPE86Nnw-Y4p7qnoY4Ce2TKqVDde5R0aC4-zw@mail.gmail.com>
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/o_NGmP2QsgKPy2ic_HO-UTqtrik>
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: Fri, 21 Aug 2020 18:45:02 -0000

George,

Thanks for the background re RTA. I think your comments address the 
issue Martin raised:

the data structure is designed to be "complete outside of a repo" and, 
unlike the other objects at a pub point, this one carries a full 
validation path to some TA, not to the CA associated with the pub point.

So, I don't think an RTA should be stored in the RPKI repo system, and 
thus it ought not appear in a manifest.

You raise the "meta-question"of whether the set of data items that can 
be stored at a pub point, and thus included on a manifest, is bounded. I 
believe that new data items might be defined for storage in the repo 
system, and that, if they are, they should be covered by the manifest. 
However, such items ought to be consistent with the overall RPKI 
functionality, not just signed objects that someone wants to piggyback 
on the RPKI repo system. Let's not encourage the RPKI to be more like an 
IRR DB.

Steve

> FYI we fully intend resubmitting RTA, we were waiting for the second
> implementation (the work Martin is doing) to have input of merit to
> spin the new version. It would be plausible to resubmit for the
> November IETF. Two running code!
>
> We designed RTA to be complete outside of a repo, so it can be used
> privately between B2B partners. Not that its things cannot "be" on the
> manifest, but that there is no dependency on the repo framework beyond
> the TA, because the passed data is the chain for validation. This
> matters to people who want to conduct activity outside of the BGP
> validation problem, which is an 'all data needed' problem. B2B uses of
> RTA are not directly about all data. Its different. (provisioning is
> typically the use case here and the intent is to show the request to
> route, originate, provision is valid, because control of the resource
> can be demonstrated. its inherently a one-to-one conversation)
>
> RTA objects have an OID, are in the registry of types. So there is a
> meta-question implicit here, that the set of OID which can be
> referenced from a Manifest is NOT bound, and CAN increase, so
> validators have to be written in a way which expect to deal with
> unknown signed things: The system is not closed, and there will be
> others in future. I think the validation of a manifest MUST NOT fail
> simply because unknown objects exist on the Manifest, especially if
> the OID lies in the arc of RPKI definitions.
>
> Martin's question is also on the other side of the deal: If a manifest
> is showing a repository is incomplete, does it cause formal
> invalidation of all things in the manifest, which has potential to
> make validation of the 'complete' chain we send in RTA not work
> because now, an object on the RTA validation path is questioned for
> other reasons.
>
> I tend to the view that only things which invalidate the certificates
> matter, ROA or other elements are not contributing to the validity of
> the RTA.  This is because they are not material to the validity of the
> object. If it was a 'whole repo' problem I could argue otherwise. It
> is not. It is inherently constrained.
>
> Specifically Missing CRL.. I have more concerns about. That would mean
> we cannot authentically deny the objects being validated.
>
> -G
>
> On Tue, Aug 18, 2020 at 4:37 PM Martin Hoffmann<martin@opennetlabs.com>  wrote:
>> Stephen Kent wrote:
>>> 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?
>> No, I am talking about a case where the ROA can be fetched successfully
>> and matches the manifest hash, but its EE certificate is expired.
>> Section 6.4 says that "if [files] fail the validity tests specified in
>> [RFC6488]", the fetch has failed. Thus, the expired EE certificate in
>> the ROA fails the complete fetch of all objects associated with the CA.
>>
>> So, not replacing an expired ROA in a publication point makes the
>> entire CA not update anymore. I.e., any other objects that now expire
>> cannot be replaced until that ROA is also replaced.
>>
>> You could argue “Don’t do that, then” but this approach doesn’t make
>> the RPKI more robust but rather makes it break more easily on simple
>> oversights.
>>
>>>> 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.
>> How do you introduce new object types in this case? There will always
>> be relying parties that run old software that doesn’t know of them. You
>> rather have to assume that objects of unknown types are signed objects
>> with unknown content. If you do that, the current draft stipulates that
>> you have to read, parse, and validate them -- and then throw away the
>> content.
>>
>> This still means that all object types added to the RPKI must be signed
>> objects. Whether that is okay or not, I don’t quite know.
>>
>>> 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?
>> I would like the document to explicitly state how to deal with object
>> types appearing on a manifest that a replying party does not know. If
>> nothing else then to make the document more helpful for implementers.
>>
>>>> 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 ...
>> RTA validates signed objects distributed via alternative means using
>> the PKI published as part of the RPKI. I.e., one of the CA
>> certificates published via the RPKI has issued the EE certificate used
>> in that signed object.
>>
>> In order to validate that object, I do not need to look at any ROAs or
>> GBRs, only certificates, CRLs, and manifests.
>>
>> Should validation of that object fail if there is an expired ROA
>> published by one of the CAs along the validation chain?
>>
>> Kind regards,
>> Martin
>>
>> _______________________________________________
>> Sidrops mailing list
>> Sidrops@ietf.org
>> https://www.ietf.org/mailman/listinfo/sidrops