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

From: Adianto Wibisono <[email-masked]>
Date: Tue, 1 Feb 2022 13:33:52 +0100

Hi all,

It is indeed a better text.

Minor nit however, we will have 'in-flight modification' that only 
appears in the abstract, but not elaborated further on the draft.
The old abstract is elaborated nicely on the first paragraph of the 
draft, explaining that we have the manifest to protect against replay 
attacks and unauthorized deletions.

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

Perhaps if we want to keep in-flight modification in the abstract, we 
need to elaborate further in the draft,
since usually I expect abstract to be a compressed version of what will 
be elaborated later.

Cheers,

Adianto

On 31/01/2022 18:56, Christopher Morrow wrote:
> oh yea, that's nice :) I was struggling with the sentence myself (upon 
> re-reading eric's question) .. since it seems to be talking about:
>   "you have a remote copy (the RP) and your copy, the manifest helps 
> you tell what's going to change in the local copy"
>   (missing the context of local/remote copy correlation did me in)
>
> anyway, yay! better text.
>
> On Mon, Jan 31, 2022 at 11:38 AM Russ Housley <[email-masked]> 
> wrote:
>
>     I think this is an improvement.
>
>     Russ
>
>     > On Jan 31, 2022, at 11:16 AM, Job Snijders
>     <job=[email-masked]> wrote:
>     >
>     > Dear Éric,
>     >
>     > I think you raise a "valid" concern (no pun intended ;-))
>     >
>     > I think something along the following lines might help clarify the
>     > purpose of RPKI Manifests.
>     >
>     > OLD:
>     >    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.
>     >
>     > NEW:
>     >    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, in-flight modification, or
>     >    unauthorized deletion of signed objects.
>     >
>     > What do others think?
>     >
>     > Kind regards,
>     >
>     > Job
>     >
>     > On Mon, Jan 31, 2022 at 02:59:31AM -0800, Éric Vyncke via
>     Datatracker wrote:
>     >> Éric Vyncke has entered the following ballot position for
>     >> draft-ietf-sidrops-6486bis-09: No Objection
>     >>
>     >> When responding, please keep the subject line intact and reply
>     to all
>     >> email addresses included in the To and CC lines. (Feel free to
>     cut this
>     >> introductory paragraph, however.)
>     >>
>     >>
>     >> Please refer to
>     https://www.ietf.org/blog/handling-iesg-ballot-positions/
>     >> for more information about how to handle DISCUSS and COMMENT
>     positions.
>     >>
>     >>
>     >> The document, along with other ballot positions, can be found here:
>     >> https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/
>     >>
>     >>
>     >>
>     >>
>     ----------------------------------------------------------------------
>     >> COMMENT:
>     >>
>     ----------------------------------------------------------------------
>     >>
>     >> Thank you for the work put into this document.
>     >>
>     >> Please find below one non-blocking COMMENT points.
>     >>
>     >> Special thanks to Chris Morrow for the shepherd's write-up
>     including the
>     >> section about the WG consensus (even if I would have appreciated a
>     >> justification for the PS status).
>     >>
>     >> I hope that this helps to improve the document,
>     >>
>     >> Regards,
>     >>
>     >> -éric
>     >>
>     >> -- Abstract --
>     >> In "then the RP can detect "stale" (valid) data", is "valid"
>     really the right
>     >> word to use ? I would naively expect "invalid". Or is it just
>     an indication
>     >> that the data *was* valid and is stale? The use of "(.*)" in
>     the abstract was
>     >> more to explain the previous word and this use is different and
>     could confuse
>     >> the reader.
>     >>
>     >>
>     >>
>     >> _______________________________________________
>     >> Sidrops mailing list
>     >> [email-masked]
>     >> https://www.ietf.org/mailman/listinfo/sidrops
>     >
>     > _______________________________________________
>     > Sidrops mailing list
>     > [email-masked]
>     > https://www.ietf.org/mailman/listinfo/sidrops
>
>     _______________________________________________
>     Sidrops mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/sidrops
>
>
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Thu, 3 Feb 2022 15:43:02 +0100

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 <[email-masked]>
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>