[sidr] [Technical Errata Reported] RFC8182 (6919)
RFC Errata System <rfc-editor@rfc-editor.org> Mon, 04 April 2022 12:47 UTC
Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DDC3A04BC for <sidr@ietfa.amsl.com>; Mon, 4 Apr 2022 05:47:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 JwcMvX_Qo1rT for <sidr@ietfa.amsl.com>; Mon, 4 Apr 2022 05:46:56 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99473A043C for <sidr@ietf.org>; Mon, 4 Apr 2022 05:46:56 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 8D9BF31790; Mon, 4 Apr 2022 05:46:56 -0700 (PDT)
To: tim@ripe.net, oleg@ripe.net, bryan@cobenian.com, sra@hactrn.net, aretana.ietf@gmail.com, jgs@juniper.net, martin.vigoureux@nokia.com, morrowc@ops-netman.net, sandy@tislabs.com
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: tdekock@ripe.net, sidr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220404124656.8D9BF31790@rfcpa.amsl.com>
Date: Mon, 04 Apr 2022 05:46:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/qYDzPMW6y36zy5MU0enwFEpd7Mg>
Subject: [sidr] [Technical Errata Reported] RFC8182 (6919)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Apr 2022 12:47:02 -0000
The following errata report has been submitted for RFC8182, "The RPKI Repository Delta Protocol (RRDP)". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6919 -------------------------------------- Type: Technical Reported by: Ties de Kock <tdekock@ripe.net> Section: 3.4.2 Original Text ------------- o When a Relying Party encounters a "withdraw" element, or a "publish" element where an object is replaced, in a delta that it retrieves from a Repository Server, it MUST verify that the object to be withdrawn or replaced was retrieved from this same Repository Server before applying the appropriate action. Failing to do so will leave the Relying Party vulnerable to malicious Repository Servers instructing it to delete or change arbitrary objects. Corrected Text -------------- o When a Relying Party encounters a "withdraw" element, or a "publish" element where an object is replaced, in a delta that it retrieves from a Repository Server, it MUST verify that the object to be withdrawn or replaced was retrieved from this same Repository Server before applying the appropriate action. Failing to do so will leave the Relying Party vulnerable to malicious Repository Servers instructing it to delete or change arbitrary objects. o For a "publish" or "withdraw" element, the hash MUST be present if the publication operation is overwriting an existing object, and it MUST NOT be present if this publication operation is writing to a new URI where no prior object exists. Presence of an object when no "hash" attribute has been specified is an error, as is absence of an object or an incorrect hash value when a "hash" attribute has been specified. In this situation this file MUST be rejected. Notes ----- Text taken from RFC8181. For <publish> elements in RRDP deltas, the same process described in RFC8181 applies; "the hash of a publish MUST match to overwrite the existing file" (This gap in the specification was independently spotted by C.J. around the same time) Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8182 (draft-ietf-sidr-delta-protocol-08) -------------------------------------- Title : The RPKI Repository Delta Protocol (RRDP) Publication Date : July 2017 Author(s) : T. Bruijnzeels, O. Muravskiy, B. Weber, R. Austein Category : PROPOSED STANDARD Source : Secure Inter-Domain Routing Area : Routing Stream : IETF Verifying Party : IESG
- [sidr] [Technical Errata Reported] RFC8182 (6919) RFC Errata System