Re: [Sidrops] Éric Vyncke's No Objection on draft-ietf-sidrops-6486bis-09: (with COMMENT)

[Job Snijders <[e-mail]>]

Dear IESG, SIDROPS, other interested parties,

Logistics: In consultation with the authors & wg chairs I now hold the
editoral token for this draft. I've uploaded the draft XML to github and
adhere to a 'one sentence per line' style to make diff reading easier.

Adianto - thank you for pointing out that the abstract and introduction
didn't connect well. I've adjusted both slightly in hopes readability is
improved.

https://github.com/job/draft-ietf-sidrops-6486bis/commit/ce3c5bae1b8e6fdd6c1f55718fb86c7db44c313e

A copy of the changeset for archival purposes is avaliable below:

Kind regards,

Job

commit ce3c5bae1b8e6fdd6c1f55718fb86c7db44c313e
Author: Job Snijders <[e-mail]>
Date:   Thu Feb 3 14:36:47 2022 +0000

    Incorporate feedback from Adianto
    
    https://mailarchive.ietf.org/arch/msg/sidrops/38TER8ns8vGqTgfBObwYRg7gSos/

diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml
index f059e20..d262f29 100644
--- draft-ietf-sidrops-6486bis.xml
+++ draft-ietf-sidrops-6486bis.xml
@@ -69,7 +69,7 @@
    A manifest is a signed object (file) that contains a listing of all the signed objects (files) in the repository publication point (directory) associated with an authority responsible for publishing in the repository.
    For each certificate, Certificate Revocation List (CRL), or other type of signed objects issued by the authority that are published at this repository publication point, the manifest contains both the name of the file containing the object and a hash of the file content.
    Manifests are intended to enable a relying party (RP) to detect certain forms of attacks against a repository.
-   Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect "stale" (valid) data and deletion of signed objects.
+   Specifically, if an RP checks a manifest's contents against the signed objects retrieved from a repository publication point, then the RP can detect replay attacks, and unauthorized in-flight modification or deletion of signed objects.
    This document obsoletes RFC 6486.
    </t>
 
@@ -80,8 +80,8 @@
 	<section title="Introduction" anchor="sect-1"><t>
    The Resource Public Key Infrastructure (RPKI) <xref target="RFC6480"/> makes use of a distributed repository system <xref target="RFC6481"/> to make available a variety of objects needed by relying parties (RPs).
    Because all of the objects stored in the repository system are digitally signed by the entities that created them, attacks that modify these published objects are detectable by RPs.
-   However, digital signatures provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not expired, but have since been superseded) or attacks that remove an object that should be present in the repository.
-   To assist in the detection of such attacks, the RPKI repository system can make use of a signed object called a "manifest".
+   However, digital signatures alone provide no protection against attacks that substitute "stale" versions of signed objects (i.e., objects that were valid and have not yet expired, but have since been superseded), or in-flight attacks that remove an object that should be present in the repository.
+   To assist in the detection of such attacks, RPKI repository systems make use of a signed object called a "manifest".
    </t>
 
 	<t>
@@ -635,7 +635,7 @@
 	<section title="Acknowledgements" anchor="sect-10"><t>
    The authors would like to acknowledge the contributions from George Michelson and Randy Bush in the preparation of the manifest specification.
    Additionally, the authors would like to thank Mark Reynolds and Christopher Small for assistance in clarifying manifest validation and RP behavior.
-   The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, and Sean Turner for their helpful review of this document.</t>
+   The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, and Adianto Wibisono for their helpful review of this document.</t>
 	</section>
 
 	</middle>