[Sidrops] Potential manifest replay vector & solution (Was: New Version Notification for draft-ietf-sidrops-manifest-numbers-01.txt)

[Job Snijders <[e-mail]>]

Dear fellow RP developers,

I'd like to draw attention to a specific paragraph in the
draft-ietf-sidrops-manifest-numbers-01 draft:

   213     To avoid certain forms of replay attack, the RP MUST verify that the
   214     URI in the accessLocation in one of the id-ad-signedObject
   215     accessMethods in the manifest's Subject Information Access (SIA)
   216     extension exactly matches the URI presented in the RPKI Repository
   217     Delta Protocol (RRDP) [RFC8182] "publish" element or the path
   218     presented by remote rsync servers.

The above was implemented in rpki-client as following, note the commit message:
https://github.com/openbsd/src/commit/024ae3e4d09de1e53e9c73c8b57fadd486087db6

Background: technically, multiple different CAs could use the same
keypair in multiple places in the RPKI. The RPKI also doesn't have
'proof of possession': for example, one can use openssl '-force_pubkey'
and '-set_subject' to sign over an arbitrary public key and then copy
that CA's yesterday's manifest & products back into the system.

I can envision various convoluted approaches to 'gracefully' merge
information and complicate the certification path validation algorithm -
but ... let's not.

To me it seems the simplest solution is for RPs to just check whether
'unsigned' meta data (the URL) information provided by the publication
point aligns with the signed data inside the Manifest object itself,
it's signedObject location. This way replay attempts will fail.

All existing deployed CAs appear to precisely and correctly align
signedObject with how things are made to appear via rsync and RRDP. This
new RP requirement does not break backwards compatibility for anyone.

Reach out to me onlist or offlist if you need help wrapping your head
around this one!

Kind regards,

Job

On Mon, Jun 10, 2024 at 02:37:07PM -0700, [e-mail] wrote:
> A new version of Internet-Draft draft-ietf-sidrops-manifest-numbers-01.txt has
> been successfully submitted by Tom Harrison and posted to the
> IETF repository.
> 
> Name:     draft-ietf-sidrops-manifest-numbers
> Revision: 01
> Title:    RPKI Manifest Number Handling
> Date:     2024-06-10
> Group:    sidrops
> Pages:    12
> URL:      https://www.ietf.org/archive/id/draft-ietf-sidrops-manifest-numbers-01.txt
> Status:   https://datatracker.ietf.org/doc/draft-ietf-sidrops-manifest-numbers/
> HTMLized: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-manifest-numbers
> Diff:     https://author-tools.ietf.org/iddiff?url2=draft-ietf-sidrops-manifest-numbers-01
> 
> Abstract:
> 
>    The Resource Public Key Infrastructure (RPKI) makes use of signed
>    objects called manifests.  A manifest lists each file that a
>    publisher intends to include within an RPKI repository, and can be
>    used to detect certain forms of attack against a repository.
>    Manifests include a "manifest number" (manifestNumber), which the
>    publisher must increment whenever it issues a new manifest, and
>    Relying Parties (RPs) are required to verify that a newly-retrieved
>    manifest for a given Certification Authority (CA) has a higher
>    manifestNumber than the previously-validated manifest.  However, the
>    manifestNumber field is 20 octets in length (i.e. not unbounded), and
>    no behaviour is specified for when a manifestNumber reaches the
>    largest possible value.  This document specifies publisher and RP
>    behaviour for this scenario.
> 
> 
> 
> The IETF Secretariat
> 
>