Penetration Test Report for RPKI
Dear colleagues, We are continuing our efforts to strengthen the security, compliance, and transparency of the RPKI system. Following on from last year's work, we asked an external party, Radically Open Security (ROS), to carry out a penetration test of our RPKI software from a user perspective earlier this year. ROS has shared a penetration test report on their findings. This testing complements the source code audit report published on 3 December. You can now find the Penetration Test Report by Radically Open Security and our response to their findings on our website [0]. We hope you will find these reports useful, and we look forward to your feedback. [0] - https://www.ripe.net/manage-ips-and-asns/resource-management/rpki/security-a... Kind regards, Bart Bakker Senior Software Engineer RIPE NCC
We hope you will find these reports useful
very much so. thank you. btw, re RIPE-009 - Unencrypted Communication in the up/down protocol, objects are cms wrapped and hence signed and objct authenticated; i.e. i would not panic about transport cia. otoh, i suspect there could be a path to move your delegated CAs to TLS; which might be conservative in the long run. randy --- randy@psg.com `gpg --locate-external-keys --auto-key-locate wkd randy@psg.com` signatures are back, thanks to dmarc header butchery
On Tue, Dec 21, 2021 at 01:23:01PM -0800, Randy Bush wrote:
We hope you will find these reports useful
very much so. thank you.
Yes, I'd like to echo what Randy says. Thanks for sharing this.
btw, re RIPE-009 - Unencrypted Communication
in the up/down protocol, objects are cms wrapped and hence signed and objct authenticated; i.e. i would not panic about transport cia.
Indeed. But I can imagine that in a world where virtually all (originally HTTP-only yolo) APIs now have been migrated to HTTPS, any API which ** by design ** is HTTP-only, would indeed stand out to pentest researchers. I think it is good the testers noticed this aspect, and also good that RIPE NCC noted in the response "Up-down remains on HTTP and uses a CMS wrapper for authentication." The up/down protocol is somewhat similar in terms of security considerations to how one can transport signed RPKI data from Publication Point (repositories) to Relaying Party (validator instances). In that context too, the use of unencrypted transport (like RSYNC, or PIGEON) is deemed acceptable because the threat model is based on a robust interpretation of object-security** to such an extend that transport-security is inconsequential.
otoh, i suspect there could be a path to move your delegated CAs to TLS; which might be conservative in the long run.
Would you mind elaborating on what you mean with the phrase "might be conservative in the long run?". Kind regards, Job ** One crucial corner stone to the concept of 'RPKI object security' is a thing called "RPKI Manifests". Manifests are an elegant and very powerful idea in the X.509 universe: the ability to securely group objects together. All modern validators use manifests: make sure your validator is updated to the latest version! Read more about what Manifests are here: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-09 This doc is now going through IETF last-call.
Hi Job, Randy,
On 21 Dec 2021, at 23:57, Job Snijders via routing-wg <routing-wg@ripe.net> wrote:
On Tue, Dec 21, 2021 at 01:23:01PM -0800, Randy Bush wrote:
We hope you will find these reports useful
very much so. thank you.
Yes, I'd like to echo what Randy says. Thanks for sharing this.
btw, re RIPE-009 - Unencrypted Communication
in the up/down protocol, objects are cms wrapped and hence signed and objct authenticated; i.e. i would not panic about transport cia.
Indeed. But I can imagine that in a world where virtually all (originally HTTP-only yolo) APIs now have been migrated to HTTPS, any API which ** by design ** is HTTP-only, would indeed stand out to pentest researchers.
I think it is good the testers noticed this aspect, and also good that RIPE NCC noted in the response "Up-down remains on HTTP and uses a CMS wrapper for authentication."
The up/down protocol is somewhat similar in terms of security considerations to how one can transport signed RPKI data from Publication Point (repositories) to Relaying Party (validator instances). In that context too, the use of unencrypted transport (like RSYNC, or PIGEON) is deemed acceptable because the threat model is based on a robust interpretation of object-security** to such an extend that transport-security is inconsequential.
I agree with that assessment. Any plaintext endpoint that could use TLS stands out. And in general, that is for a good reason, TLS provides encryption, authentication, and integrity - which are good properties to have. For published RPKI objects, encryption is not needed and the object-security model offers authentication and integrity.
otoh, i suspect there could be a path to move your delegated CAs to TLS; which might be conservative in the long run.
Would you mind elaborating on what you mean with the phrase "might be conservative in the long run?".
Moving delegated CAs to TLS would protect against currently unknown attacks. It is defence in depth. I would strongly prefer this endpoint to use TLS; there is a story on the RPKI backlog to move the delegated CAs to TLS. Kind regards, Ties —
Kind regards,
Job
** One crucial corner stone to the concept of 'RPKI object security' is a thing called "RPKI Manifests". Manifests are an elegant and very powerful idea in the X.509 universe: the ability to securely group objects together. All modern validators use manifests: make sure your validator is updated to the latest version! Read more about what Manifests are here: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-6486bis-09 This doc is now going through IETF last-call.
--
To unsubscribe from this mailing list, get a password reminder, or change your subscription options, please visit: https://lists.ripe.net/mailman/listinfo/routing-wg
participants (4)
-
Bart Bakker -
Job Snijders -
Randy Bush -
Ties de Kock