> On 22 Oct 2024, at 14:30, Job Snijders <[email protected]> wrote: > > 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. >
How they are (intended to be) distributed is irrelevant. PGP signed files are normally not published publicly; nonetheless, there have been demonstrated weaknesses in protocols built upon them because of a signer being confused into signing the wrong thing >> 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 '-'. Constrained in the sense of containing reserved values or otherwise not permitting ad-hoc use >> 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. It is signing a checksum listing, yes. But how is it supposed to bind that to a purpose? How, especially in an automated system, is it supposed to ensure that it is only signing checklists that achieve what the system requesting signing desires? > 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? Fundamentally it doesn’t need to be hardcoded to a single specific purpose, but any mechanism should be sufficiently specific that it is possible for the CA and any intermediaries to know that what they are being asked to sign is the correct thing > 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. To be blunt, we have known that it is not possible to (generally) build secure systems on such deficient primitives for over a decade now. I first read about this in a blog post in 2015 [1] and the idea was not new at the time. If you do not appropriately domain separate what you are signing, then you - frankly - do not truly know what you are signing; as that blog post demonstrates, it is not especially difficult to produce files that can be validly interpreted in multiple formats. It is not a mistake that CMS signs over the content type. But filenames are an abysmal medium for doing this. To avoid risk of exploitation, the content type distinguishers should either be allocated from an IANA managed registry, or from a collision resistant namespace (e.g. URLs, UUIDs, OIDs, reverse-DNS, …) - Erin [1] https://sandstorm.io/news/2015-05-01-is-that-ascii-or-protobuf _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
