This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/cooperation-wg@ripe.net/
[cooperation-wg] IS3C consultation on an alternative narrative to deploy Internet standards
- Previous message (by thread): [cooperation-wg] IS3C consultation on an alternative narrative to deploy Internet standards
- Next message (by thread): [cooperation-wg] Discuss ISO-3166 mark TAIWAN as a Provinces of China on the RIPE NCC website
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Nick Hilliard
nick at foobar.org
Mon Mar 11 17:22:43 CET 2024
Hi Wout, I'm concerned about this approach to networking security for a numbers of reasons. 1. Mixing unrelated technologies RPKI and DNSSEC are fundamentally different technologies with different applications in the networking stack. I don't think it's productive to mix the two together in the same discussion space because their aims and outcomes are significantly different. 2. It's unclear what is being proposed DNSSEC can be deployed at a resolver level, or at a domain level or at the registrars. The use cases for each of these scenarios vary widely. At the domain level, as Michele mentioned, DNSSEC is a notoriously brittle and complex protocol and while it may be relevant and appropriate for institutions or large enterprises, it's not really appropriate for smaller organisations or individuals which comprise the majority of registered domains. Further up the chain at registrars and registries, it's also complex, as the recent .ru outage showed. Smaller registrars may easily end up causing more damage than they secure, and there would be good arguments for DNSSEC not to be a mandatory component of registrar service. RPKI can be "deployed" as either creating ROA objects, or else by implementing RPKI policy at the networking level using validators and routing policies. Again, these are two entirely different things with different security goals and outcomes, but there is no clear indication of what the IS3C consultation is actually promoting. Overall, RPKI can be helpful to address certain styles of accidental network configuration, but it is not a technology which can be used to protect against dedicated security threat actors. 3. Over-focusing on individual security elements Security management is a wide-ranging process-oriented mechanism rather than an outcome of applying specific security-related technology components. There would be no reason not to include assessment of RPKI or DNSSEC as part of a more general information security management assessment assessment process, but in the scale of things, they are individual components of a larger security management whole, and operationally they are by no means among the more important components for most organisations. 4. Unclear what the focus outcome is intended to be There isn't a clear problem statement or any indication about why it's more important to prioritise RPKI and DNSSEC over other discrete technology building blocks. For example, in terms of routing security, the MANRS programs provide a useful and well accepted set of compliance items, of which RPKI is one of the optional components, i.e. not even mandatory (disclosure: I am a MANRS SC member, but this email reflects my personal opinions). The thing that will help the Internet's overall security is adherence to Internet good practice documents, and at the next level, adoption and compliance with general security management frameworks (there are plenty of these). Hyper-focus on individual line items will distract attention away from these aims and the outcome of focusing on individual security items in the way that this consultation suggests is likely to come at the cost of the whole. Nick Wout de Natris wrote on 11/03/2024 10:00: > Dear colleagues, > > IGF DC IS3C invites you to participate in the consultation on > positively enhancing the deployment of two Internet standards: DNSSEC > and RPKI. You are invited to answer either of these questions: Do the > arguments used to favor a positive decision, convince you to order > deployment within your organisation or from your service provider? / > Do they assist you to convince decision takers in your organisation to > invest in security by design? You are invited to share your views and > arguments with IS3C’s expert team and have been granted commenting > rights in this document to do so. The consultation runs from 11 March > to 12PM UTC, Friday 5 April 2024. Your contribution will be taken into > consideration when finalising the text before publication this spring. > Here is the link to the Google Doc: > > > https://docs.google.com/document/d/1YYq3ie9D03L1Z5ssgPbWKV5becUgNw0h7_fmm9xGWKs/edit?usp=sharing > > > We hope to receive your views so we can present the most convincing > arguments to deploy DNSSEC, RPKI and all other security-related > Internet standards and ICT best practices. (FYI, this project us > sponsored by ICANN and RIPE NCC.) > > Kind regards, > > Wout de Natris > > IS3C: Making the Internet more secure and safer > > -------------- next part -------------- An HTML attachment was scrubbed... URL: </ripe/mail/archives/cooperation-wg/attachments/20240311/3891d3bb/attachment.html>
- Previous message (by thread): [cooperation-wg] IS3C consultation on an alternative narrative to deploy Internet standards
- Next message (by thread): [cooperation-wg] Discuss ISO-3166 mark TAIWAN as a Provinces of China on the RIPE NCC website
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]