Subject: [Sidrops] I-D Action: draft-ietf-sidrops-6486bis-07.txt

From: [email-masked]
Date: Thu, 14 Oct 2021 07:15:30 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIDR Operations WG of the IETF.

        Title           : Manifests for the Resource Public Key Infrastructure (RPKI)
        Authors         : Rob Austein
                          Geoff Huston
                          Stephen Kent
                          Matt Lepinski
	Filename        : draft-ietf-sidrops-6486bis-07.txt
	Pages           : 16
	Date            : 2021-10-14

Abstract:
   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 IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-6486bis/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-6486bis-07

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ties de Kock <[email-masked]>
Date: Thu, 14 Oct 2021 17:07:33 +0200

Steve,

Thanks for adding text clarifying the handling of manifestNumber and thisUpdate.

> On 14 Oct 2021, at 16:15, [email-masked] wrote:
> 
> 

While reading the diff I thought it would be good to discuss this on list:

> 4.2.1:
> 
>       This field is an integer that is incremented (by 1) each time a
>       new manifest is issued for a given publication point.  This field
>       allows an RP to detect gaps in a sequence of published manifests.

I would really like it if we could leave this open and allow arbitrary
increments. It's what is out there in the wild, and RPs can not check anything
against manifestnumber either: Not all of them are guaranteed to be visible. 
Strict incrementing counters are also a point of contention in implementations
due to database locking on the parent CA.

Existence/absense of manifests of a compliant CA is visible through the CRL. And
it does not make behaviour of a sloppy CA invisible.

I would also like to revisit 4.2.2.

>   letter extension.  The extension MUST be one of those enumerated in
>   the "RPKI Repository Naming Scheme" registry maintained by IANA
>   [IANA-NAMING].

Since the content of the registry is dynamic, I think it would be good to
clarify that encountering an unknown extension must not result in a failed fetch.
If RPs become intolerant to new filenames using an extension not in the
registry (for example .asa) would require a flag day. 

While reducing ambiguity in the results that RPs have when processing manifests
is good I don't think rejecting unknown types is worth the downside.

Kind regards,
Ties

---

From: Stephen Kent <[email-masked]>
Date: Thu, 14 Oct 2021 12:15:10 -0400

Ties,
> it does not make behaviour of a sloppy CA invisible.

I made this change in response to a request from Ben Madison on 9/30. 
You did not comment on his suggestion then, or over the next 13 days. 
Why are arbitrary increments a "good thing?" Why are they out there now? 
Which CA's don't know how to count by 1?

The text does not require that an RP verify that the increment is 
monotonic, just that the new manifest has a nigher number than any 
previously-validated manifests from the same issuer. I don't see a need 
to change this.

> is good I don't think rejecting unknown types is worth the downside.

This text has not changed since version 4, posted in May of this year. 
It's way too late in this process to comment on this now, almost 6 
months later.

Steve

---

From: Job Snijders <[email-masked]>
Date: Thu, 14 Oct 2021 18:22:52 +0200

> against manifestnumber either: Not all of them are guaranteed to be visible. 

But isn't that kind of the point though? To be able to detect whether an
RP saw all of them, because it is not guaranteed an RP will have
visibility into all of them?

> due to database locking on the parent CA.

Can you elaborate on this aspect?

> is good I don't think rejecting unknown types is worth the downside.

A flag day can be avoided by putting the .asa object in its own
Publication Point: then the PP fails on older RPs (which is not a
problem), and works as expected on newer RPs.

Since for (for example) the .asa object type the early allocation
process is used, I think there is sufficient time between
'new idea' -> IANA registry update -> 'deployment in the wild'.

RP implementers need to stay up-to-date on what RPKI object types
currently exist, which seems reasonable. I think there is value in clear
guidance on what RPs should expect and not expect.

For example, rpki-client only attempts to sync currently known
filetypes, this hopefully limits the (potential) garbage RPs pull in:
https://github.com/openbsd/src/commit/22ca817fdd32d4cc08710821dad014cf18d1cd85

Kind regards,

Job

---

From: Ties de Kock <[email-masked]>
Date: Fri, 15 Oct 2021 13:25:05 +0200

Hi Job,

I don't expect changes to the draft this late in the process, but I think
it would be good to share these concerns.

> On 14 Oct 2021, at 18:22, Job Snijders <job=[email-masked]> wrote:
> 

What would an RP learn from this? Are there any attacks that this visibility
can prevent?

Keep in mind that a malicious CA can sign whatever it wants. And that an on-path
attacker or malicious repository can make objects valid/invalid by presenting
different sets of objects (so there is no need to sign objects if you want to
remove objects from validation).

At the same time, there are many legitimate scenarios in which an update is
never externally observable. So RPs can not 'learn' anything from it - it will
happen many times a day. I will describe a straightforward one below:

We consider a CA that processed ~2K updates an hour in a repository. Two objects
on the same manifest are updated in short succession. After each update, a new 
manifest is issued. The CA supports RRDP and rsync.

The updates are sent to a RRDP publication server synchronously (unlikely for
real implementations). The RRDP publication server processes the two publish
(w/ hash, so replace) operations before issuing the next delta. The update is
never visible in RRDP.

The rsync repository is written to disk batch-wise and revisions are kept around
for two hours. The CA does not have the performance (e.g. disk space, IOPS,
iO bandwidth) to write all 2000 revisions an hour to disk. The rsync repository
is written after both updates are processed. The update is never visible in
rsync.

In some scenarios (a lot of updates, or during a key-roll) you can even have
_many_ manifests that are not visible this way.

TLDR: I argue that in the real world, (potentially many) manifest updates will
never be externally observable and that a malicious repository can often cause
the same result for RPs, without signed objects.

At the same time RPKI has a beautiful property compared to the web PKI: an object
needs to be widely visible (and thus easy to detect!) to affect the default free
zone.

If you have an attack scenario where you can detect the behaviour of a malicious
CA this way, while that attack can not be performed by an on-path attacker,
please elaborate.

> Can you elaborate on this aspect?

It is an implementation detail about parallelism and fine-grained locking (on DB
level) that does not lend itself well to description on a list. For manifests it
likely is no real concern. For serial numbers our implementation needs arbitary
increments due to this concern.

> problem), and works as expected on newer RPs.

This is a lot of implementation work if there is no attack that it prevents.
It also forces a CA to triple (the CA needs to maintain the PP incoming from
parent plus two children) the number of manifests it needs to keep up to date
per CA, or update less often and open a longer window for replay attacks.

What do you think of his strategy:
  * RPs that do not download unknown extensions do not consider those when
	validating a manifest. Unknown files can not result in a failed fetch.
  * If a new object is "safe" (it does not change the meaning of other objects
	such as GBR) we can add the object with the same manifest version.
  * A new object profile that changes, to whatever degree, the effect of objects
	on the current manifest, requires a new (minimal) version of the manifest.

> guidance on what RPs should expect and not expect.

While I think people should update quickly, given the update rate I see in data
I think this is a tricky route to go. Updates are slow. For example: despite a
lot of effort there are still ~240 active RPKI Validator 3 instances out there
and about half of those appear to be builds from more than a year old [0].

> https://github.com/openbsd/src/commit/22ca817fdd32d4cc08710821dad014cf18d1cd85

That is a nice local improvement in security! 

Kind regards,
Ties

[0]: Current numbers will differ - I read this from a chart with data up to the
first of september.

> 
> Kind regards,
> 
> Job
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Job Snijders <[email-masked]>
Date: Fri, 15 Oct 2021 16:39:26 +0200

On Fri, Oct 15, 2021 at 01:25:05PM +0200, Ties de Kock wrote:
> What would an RP learn from this? Are there any attacks that this
> visibility can prevent?

I consider it useful debugging information.

> What do you think of this strategy:

The above strategy matches OpenBSD's RP implementation as far as I
understand: when an unknown file type is encountered on a Manifest, a
log message is emitted "unsupported file type: %s", after which the
unknown file is discarded. Only recognized file types will be processed
(currently: GBR, ROA, CER, CRL).

> 	on the current manifest, requires a new (minimal) version of the manifest.

Yes, in theory. This list discussed Manifest profile version numbers a
few weeks ago. I think most agreed that deploying a change to the
Manifest profile version at any point in the future, will be challenging.

Kind regards,

Job

---

From: Job Snijders <[email-masked]>
Date: Fri, 15 Oct 2021 17:20:50 +0200

On Fri, Oct 15, 2021 at 01:25:05PM +0200, Ties de Kock wrote:
> Two objects on the same manifest are updated in short succession.
> After each update, a new manifest is issued. The CA supports RRDP and
> rsync.
> 
> The updates are sent to a RRDP publication server synchronously
> (unlikely for real implementations). The RRDP publication server
> processes the two publish (w/ hash, so replace) operations before
> issuing the next delta. The update is never visible in RRDP.

Indeed in the scenario you describe one of the two updates itself is not
be visible in RRDP/RSYNC ('because overtaken by events'), but what *is*
visible is that an update was 'lost' somewhere. (knowing that 'loss'
doesn't necessarily mean 'bad').

Visibility into 'update loss' can be valueable information to monitor
over time in context of understanding pipeline efficiency.

If a CA + publication server system (in normal operating mode)
exhibits monotonic increments, but ... at specific timesofday/workloads
shows gaps, it might warrant investigation by operators.

Summary
=======

Trusting CA's to increment monotonically for each new manifest,
hopefully aids operators when they need to troubleshoot RSYNC/RRDP.

And Stephen Kent confirmed that RPs are not required to verify
monotonicity [1] ... so I think we are all on the same page? :-)

Kind regards,

Job

[1]: https://mailarchive.ietf.org/arch/msg/sidrops/tUU2jV1nVu18RepnXgKeWgXEvhs/