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

[Job Snijders <[e-mail]>]

Dear Roman,

Thank you for this review!

On Wed, Feb 02, 2022 at 05:44:34PM -0800, Roman Danyliw via Datatracker wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Ben Kaduk's DISCUSS position.
> 
> ** Section 8.  The Section 4.2.1 guidance that “Each RP MUST verify that a
> purported "new" Manifest contains a higher manifestNumber than
> previously-validated Manifests” is crucial to prevent a replay-like attack. 
> What is the recovery procedure if an RP loses that state (i.e., “forgets” what
> the last manifestNumber was for a given publication point)?  Should it be TOFU
> (trust whatever is the first value it downloads next)?

Through this update I made an attempt to clarify
https://mailarchive.ietf.org/arch/msg/sidrops/NzCcNzcN46FD7RgV3D5ULMnEhxs/

If the RP has "forgotten" what the last manifestNumber was (for example,
a brand new RP instance which only has a Trust Anchor Locator in its
trust store, and an empty cache), there obviously is notthing for the RP
to compare the purported "new" Manifest against.

It is not entirely TOFU, in the sene that the cryptographic validity
through signatures is checked, and the Manifest's eContent, EE
certificate, and CRL all contain pointers to determine whether the
object at hand is is valid within the set of constraints outlined in
both the original RFC and this -bis document. 

> ** Editorial
> -- Section 1.  In the spirit of inclusive language consider replacing
> “man-in-the-middle”.  For example, s/man-in-the-middle attack on the
> retrieval/an on-path attack during the retrieval/

Updated:
https://github.com/job/draft-ietf-sidrops-6486bis/commit/83ade7f35d6e7b8379cb798e258c3cbb86278fee

> -- Section 4.2.1.  Editorial.  In the thisUpdate field, s/is recent any/is more
> recent than any/

Thanks, this was already addressed through
https://mailarchive.ietf.org/arch/msg/sidrops/EYxcUtZLF7go2UBnOoOXqwn6bRY/

Kind regards,

Job

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

    Add more inclusive language
    
    Feedback from Roman Danyliw
    
    https://mailarchive.ietf.org/arch/msg/sidrops/VFKYHp2WdsJ7yVt8fHY3hBSJnzY/

diff --git draft-ietf-sidrops-6486bis.xml draft-ietf-sidrops-6486bis.xml
index d103cf4..97db9fd 100644
--- draft-ietf-sidrops-6486bis.xml
+++ draft-ietf-sidrops-6486bis.xml
@@ -85,7 +85,7 @@
     A manifest is a signed object that enumerates all the signed objects (files) in the repository publication point (directory) that are associated with an authority responsible for publishing at that publication point.
     Each manifest contains both the name of the file containing the object and a hash of the file content, for every signed object issued by an authority that is published at the authority's repository publication point.
     A manifest is intended to allow an RP to detect unauthorized object removal or the substitution of stale versions of objects at a publication point.
-    A manifest also is intended to allow an RP to detect similar outcomes that may result from a man-in-the-middle attack on the retrieval of objects from the repository.
+    A manifest also is intended to allow an RP to detect similar outcomes that may result from an on-path attack during the retrieval of objects from the repository.
     Manifests are intended to be used in Certification Authority (CA) publication points in repositories (directories containing files that are subordinate certificates and Certificate Revocation Lists (CRLs) issued by this CA and other signed objects that are verified by End-Entity (EE) certificates issued by this CA).
    </t>
 
@@ -609,7 +609,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, Sean Turner, Adianto Wibisono, Murray Kucherawy, and Francesca Palombini for their helpful review of this document.</t>
+   The authors also wish to thank Tim Bruijnzeels, Job Snijders, Oleg Muravskiy, Sean Turner, Adianto Wibisono, Murray Kucherawy, Francesca Palombini, and Roman Danyliw for their helpful review of this document.</t>
 	</section>
 
 	</middle>