[sidr] [Errata Held for Document Update] RFC8182 (6919)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 18 April 2022 20:37 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 E86373A08C7; Mon, 18 Apr 2022 13:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.659
X-Spam-Level:
X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, 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 wqF4fHBSoKXW; Mon, 18 Apr 2022 13:37:04 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [IPv6:2001:1900:3001:11::31]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8269F3A08B1; Mon, 18 Apr 2022 13:37:04 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 04208B33A4; Mon, 18 Apr 2022 13:37:03 -0700 (PDT)
To: tdekock@ripe.net, tim@ripe.net, oleg@ripe.net, bryan@cobenian.com, sra@hactrn.net
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: aretana.ietf@gmail.com, iesg@ietf.org, sidr@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset=UTF-8
Message-Id: <20220418203703.04208B33A4@rfcpa.amsl.com>
Date: Mon, 18 Apr 2022 13:37:03 -0700 (PDT)
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidr/3GxgQccCoDCkn_KsebCdr3vfx-8>
Subject: [sidr] [Errata Held for Document Update] 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, 18 Apr 2022 20:37:09 -0000

The following errata report has been held for document update 
for RFC8182, "The RPKI Repository Delta Protocol (RRDP)". 

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6919

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Ties de Kock <tdekock@ripe.net>
Date Reported: 2022-04-04
Held by: Alvaro Retana (IESG)

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)

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