Subject: Re: [Sidrops] WGLC: draft-ietf-sidrops-6486bis - CLOSES: 10/11/2021 (Oct 11, 2021)

From: Christopher Morrow <[email-masked]>
Date: Thu, 7 Oct 2021 13:26:04 -0400

howdy folks!
This got some discussion before this WGLC message ,but none here...

So.. all good? stop? start? restart?
dance around a tree? comments on direction for this WGLC would be .. good :)

-chris

On Fri, Sep 24, 2021 at 1:58 PM Christopher Morrow <
[email-masked]> wrote:

> WG Folks:
> Please take this as a WGLC start for:
>   draft-ietf-sidrops-6486bis
>
> The abstract of such is:
>   "This document defines a "manifest" for use in the Resource Public Key
>    Infrastructure (RPKI).  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."
>
> The WGLC should finish on/about 10/11/2021 - Oct 11, 2021... There's
> already one question/comment on-list for this WGLC a pointer to which is:
>
> https://mailarchive.ietf.org/arch/msg/sidrops/rIVkaLS96MP2dbXr516Kdg35Amc
>
> Please give the -06 version of the document a read/comment and if you have
> opinions(about this document!) please express them on-list before Oct 11,
> 2021 (10/11/2021)
>
> -chris
> co-chair-persona
>

---

From: Job Snijders <[email-masked]>
Date: Thu, 7 Oct 2021 19:37:55 +0200

Hi,

> So.. all good? stop? start? restart?

All good. I'd like for the document to progress to the next stage.

Might also be a good time for people to double check their
implementation's behaviour in context of each uppercase normative term.

https://trac.ietf.org/trac/sidrops/wiki/ManifestBisImplementations

Kind regards,

Job

---

From: Randy Bush <[email-masked]>
Date: Thu, 07 Oct 2021 12:23:32 -0700

> dance around a tree? comments on direction for this WGLC would be

there has been wiggling and back and forth.  i would ask steve and russ
if they feel change was significant enough to rewind.

randy

---

From: Russ Housley <[email-masked]>
Date: Thu, 7 Oct 2021 15:44:14 -0400

> On Oct 7, 2021, at 3:23 PM, Randy Bush <[email-masked]> wrote:
> 

Please excuse th e use of non-ASCII below, but it seems the easiest way to convey the point...

To me, the changes to these three paragraphs justify moving forward with this document.
   The CA MAY choose to MUST sign only one manifest with each generated private key,
   and MUST generate a new key pair for each new version of the
   manifest.  This form of use of the associated EE certificate is
   termed a "one-time-use" EE certificate.certificate.[RFC6487]

   2.  Issue an EE certificate for this key pair.  The CA MUST revoke
       the EE certificate used for the manifest being replaced.

   An authority MUST issue a new manifest in conjunction with the
   finalization of changes made to objects in the publication point.  An
   authority MAY perform a number of object operations on a publication
   repository within the scope of a repository change before issuing a
   single manifest that covers all the operations within the scope of
   this change.  Repository operators SHOULD MUST implement some form of
   repository update procedure that mitigates, to the extent possible,
   the risk that RPs that are performing retrieval operations on the
   repository are exposed to inconsistent, transient, intermediate
   states during updates to the repository publication point (directory)
   and the associated manifest.

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 8 Oct 2021 09:59:26 +0200

Hi Russ, all,

From my perspective there is no need to rewind. I am fine with the changes
suggested by Russ.

There is one other thing though. I suggested that we consider including text
that says that all removed, or replaced objects are revoked (if they are of
a kind that can be revoked, i.e. not CRLs):
https://mailarchive.ietf.org/arch/msg/sidrops/rIVkaLS96MP2dbXr516Kdg35Amc/

My feeling from responses was that people are fine with it - and that it is
inline with the requirement to revoke replaced manifests, but this is not
my call to make. 

Tim

> On 7 Oct 2021, at 21:44, Russ Housley <[email-masked]> wrote:
> 
> 
> 
>    The CA MAY choose to MUST
>  sign only one manifest with each generated private key,
>    and 
> MUST
>  generate a new key pair for each new version of the
>    this change.  Repository operators 
> SHOULD MUST
>  implement some form of
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Stephen Kent <[email-masked]>
Date: Fri, 8 Oct 2021 11:18:43 -0500

Tim,

> a kind that can be revoked, i.e. not CRLs):

I think the  text below, which is in the new rev of the document, 
addresses your request:

If any named objects in the publication point are replaced, the 
authority MUST ensure that the file hash for each replaced objectis 
updated accordingly in the new manifest. Additionally, the authority 
MUST revoke the certificate associated with each replaced object (other 
than a CRL), if it is not expired. Steve

---

From: Stephen Kent <[email-masked]>
Date: Fri, 8 Oct 2021 11:16:26 -0500

Russ,

All of the highlighted changes you cited have been made in the next rev 
of the document.

>     The CAMAY choose to  *MUST*  sign only one manifest with each generated private key,
>     and*MUST*  generate a new key pair for each new version of the
>     termed a "one-time-use" EEcertificate.*certificate.[RFC6487]*
>
> *2. Issue*  an EE certificate for this key pair.*The CA MUST revoke the EE certificate used for the manifest being 
> replaced.*
>
>     this change.  Repository operatorsSHOULD  *MUST*  implement some form of

---

From: Russ Housley <[email-masked]>
Date: Fri, 8 Oct 2021 12:42:40 -0400

Steve:

Yes, indeed, they have.  I was responding to the questions about rollback.  I do not want these to be rolled back.

Russ

> On Oct 8, 2021, at 12:16 PM, Stephen Kent <[email-masked]> wrote:
> 
> Russ,
> 
> All of the highlighted changes you cited have been made in the next rev of the document.
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/sidrops <https://www.ietf.org/mailman/listinfo/sidrops>

---

From: Tim Bruijnzeels <[email-masked]>
Date: Fri, 8 Oct 2021 18:53:20 +0200

> On 8 Oct 2021, at 18:18, Stephen Kent <[email-masked]> wrote:
> 
> I think the  text below, which is in the new rev of the document, addresses your request:

It does. Thanks!

---

From: Ties de Kock <[email-masked]>
Date: Mon, 11 Oct 2021 09:25:29 +0200

Hi all,

> On 7 Oct 2021, at 19:26, Christopher Morrow <[email-masked]> wrote:
> 
> howdy folks!

It looks good to me.

The only gap I see is that there is no guidance  (or mandatory checks) on
manifestNumber nor requiring monotonic increase of thisUpdate (since there is no
mandated syntactic constraint). This leaves open undetectable replay attacks.

Given that we have seen monotonic counters regress in the RPKI in the wild [0],
if we add such a check, I would prefer that we check for monotonically increasing
thisUpdate.

But given that (a) an attack can already withold updates from a certain point on,
without the updates reverting and that (b) manifest expiry bounds the time
window for an undetectable attack, I think that we can skip addresing this gap.

Kind regards,
Ties

[0]: A snapshot of a non-hosted CA instance VM was made, it published some RRDP
deltas after the OS upgrade, later the snapshot was restored, causing the RRDP
serial to regress.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Oct 2021 11:37:22 -0400

Ties,Hi all,
> ...

I added the following text to the discussion of the manifestNumber in 4.2.1:

The issuer MUST increase the value of this field monotonically for each 
newly-generated Manifest.

Each RP MUST verify that a purported “new” Manifest contains a higher 
ManifestNumber than previously-validated Manifests.

the thisUpdate field is a time/date, so a "monitonic" increase is not 
the appropriate language.

I added the following text to the thisUpdate description in the same 
section.

*The issuer MUST ensure that the value of this field is more recent any 
previously-generated Manifest. * *Each RP MUST verify that this field 
value is greater (more recent) than the most recent Manifest it has 
validated.*

*
*

*
*

*Steve
*

---

From: Ties de Kock <[email-masked]>
Date: Wed, 13 Oct 2021 09:02:19 +0200

Hi Steve, all,

> On 12 Oct 2021, at 17:37, Stephen Kent <stkent=[email-masked]> wrote:
> 
> Ties,Hi all,
>> ...
> The issuer MUST increase the value of this field monotonically for each newly-generated Manifest. 
> Each RP MUST verify that a purported “new” Manifest contains a higher ManifestNumber than previously-validated Manifests.
> 
> the thisUpdate field is a time/date, so a "monitonic" increase is not the appropriate language.
> 
> I added the following text to the thisUpdate description in the same section.
> 
> 
>    The issuer MUST ensure that the value of this field is more recent any previously-generated Manifest. Each RP MUST verify that this field value is greater (more recent) than the most recent Manifest it has validated.

These two changes look good to me.

My previous concern about the impact this would have on CAs revert to older
objects (as seen in the wild) is no longer a concern for me. A CA can mitigate
that risk by using the typical serial generation strategies that incorporate the
time (e.g. unix_time_millis || 64b_of_random) - or just not losing state.

-Ties

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 14 Oct 2021 13:22:21 -0400

Backing up to the top  of the thread....

I think there was some good conversation, small changes (acceptable to all
parties) and consensus to move forward! So,
please consider this a closing comment on the WGLC, I'll kick out a
shepherds doc and push forward into the waiting arms of the
(loving?) IESG.

thanks!
-chris
co-chair-persona

---

From: Christopher Morrow <[email-masked]>
Date: Sun, 31 Oct 2021 18:45:39 -0400

this finally got done.

On Thu, Oct 14, 2021 at 1:22 PM Christopher Morrow <
[email-masked]> wrote:

>> Please give the -06 version of the document a read/comment and if you
>> have opinions(about this document!) please express them on-list before Oct
>> 11, 2021 (10/11/2021)
>>
>> -chris
>> co-chair-persona
>>
>