Date: Tue, 22 Oct 2024 12:30:01 +0000
From: Job Snijders <job@fastly.com>
To: Erin Shepherd <erin.shepherd@e43.eu>
Message-ID: <ZxeayWl_0X9XMvYF@fast>
References: 
 <CAMEWqGuteXVkJdXfn3Ls4+kFXQ+ZTDFvT23Y7O8iKNJhFfOwng@mail.gmail.com>
 <BB5B0F75-E4FB-40FB-9A5A-6DB9A9B31FDD@ripe.net>
 <Zr326KAHIudi-gdh@snel>
 <D93F6B52-AE7E-4BA2-A753-23AADA31F609@e43.eu>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <D93F6B52-AE7E-4BA2-A753-23AADA31F609@e43.eu>
Message-ID-Hash: DYOZZLW4DOCEI57OCOEISFZ3X6BDMSHG
CC: Tim Bruijnzeels <tbruijnzeels@ripe.net>,
 Q Misell <q=40as207960.net@dmarc.ietf.org>, grow@ietf.org, sidrops@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BSidrops=5D_Re=3A_=5BGROW=5D_Peering_API_Discovery_-_Use_of_sign?=
	=?utf-8?q?ed_checklists?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/sidrops/42p-BSlf2t7B0ZpKgOucmaD7Nu4>

On Tue, Oct 22, 2024 at 01:42:46PM +0200, Erin Shepherd wrote:
> In particular RSCs do not have binding of purpose (what is being
> signed) or audience (who it is being signed for).

RSCs are not distributed through the global RPKI repository system, they
are distributed through private channels.

> The latest version of the MR attempts to hack around this by requiring
> the use of two named files, one of which contains the peering API base
> URL.
>
> In 2024 we should not be designing cryptographic protocols whose
> security properties rely upon magic filenames in otherwise
> unconstrained fields.

The fileName field is optional and it is not unconstrained: characters
are constrained to [a-z], [A-Z], [0-9], '.', '_', and '-'.

> I strongly believe that, to do this to the security standards we
> should be expecting of modern-day Machine-to-Machine IETF protocols
> requires a system whereby my RPKI CA understands what I’m asking it to
> sign.

The CA understands exactly what it is doing: it is signing over a
checksum listing with a specific set of Internet Number Resources.

But on the other hand, RP should be cognizant the data in a RSC is
self-asserted. The self-asserted data thusly be applied in a context
that makes sense for the RP (for instance, if the nonce is as expected).
Then again such caution must also be applied to data derived from signed
objects that do have a purpose-specific content-type...

> That perhaps requires a new RPKI content type. Sadly, this is how
> things sometimes work out.

It sounds like instead of using specific values in the opaque 'fileName'
label field, you'd prefer to hardcode a bunch of stuff?

Ultimately an RSC is a RPKI-chained signature over one or more SHA-256
hashes. If the Peering API cannot be made to work to establish
inter-domain trust with such a fundamental building block, something is
off.

Subjectively, one might have a preference for hardcoding purposes via
content-type versus using a general purpose mechanism such as RSC; but
the fundamentals remain the same.

> (The exact form of this is of course something that would need to be
> worked out. The OAuth ecosystem would probably prefer a JWT signed by
> an RPKI-chained end entity certificate. Perhaps the request itself
> could also be signed and so could encode “Authenticate to <the peering
> API> at <https://….> for <AS12345, AS23456, …>”) 

Sure, a lot of things are possible.

Kind regards,

Job