On Thu, 17 Apr 2025 11:06:18 -0700, David Conrad via rssac-caucus wrote:
It isn’t so much that I find the report lacking, rather in my mind, it raises the question of whether the goal of RSSAC-001 E.3.6-A to "assure the community that the RSOs take implementation diversity seriously and provide a collective view of implementation choices within the root server system” is realistic/ feasible given the current structure of the RSS.
In a quick search related to RSSAC-001, I see https://root-servers.org/rssac001/ has had four reports, two by Verisign, one by Netnod and ICANN respectively (maybe there are others not on that site?), posted since RSSAC-001 came out in Dec 2015 (ICANN’s says theirs is a living document, but it doesn’t have a change log so it’s difficult to determine how frequently it has been updated). While having a periodically published aggregated report is likely preferable to (in theory) twelve different reports, (IMHO) none of those reports or the report you just published provides sufficient detail (Netnod’s, explicitly so) to derive any (additional) assurance related to diversity of implementation — in fact, it might raise more questions/concerns than it answers.
I suspect I’m aware of (some of) the perhaps intractable challenges in implementation of E.3-6-A. While I appreciate the intent and effort, without information related to (at least) distribution of technology diversity, this feels a bit like a box checking exercise. But perhaps that’s just me.
David, thanks for the feedback. I suspect it will prompt multiple RSOs to review and update their reporting. I've already seen some changes on https://root-servers.org/rssac001/ There is an important aspect that I think your note doesn't fully reflect: There is a REAL TRADE-OFF between how many operational details RSOs provide to help the community understand its diversity and robustness, and how much those details help potential adversaries. (For example, I don't think we will be asking RSOs to share their passwords so we can ensure they sufficiently diverse!) The threshold one prefers for this trade-off is something about which different technical people will reasonably disagree. I hope the community will recognize the _RSS 2025 Technical Diversity Report_ as progress, even if it's not everything you hope for. And, just speaking personally, for me, the statement that a diversity report is useless without a distribution feels a bit extreme. While knowing 48.4% of servers run bind-9.18.36 might answer some very specific questions, such a factoid would be out of date tomorrow. But to try and directly address your question: If one wanted a bounds on the distribution, it seems fair to assume that at least one RSO operators one of each of the configurations given in the report. Would something like that statement address some of your concern? If so, perhaps a future report will reflect this discussion and be at least that specific. -John ("starts with pass...", wait wait) Heidemann
Regards, -drc
On Apr 16, 2025, at 5:16 PM, Wessels, Duane <dwessels@verisign.com> wrote:
Hi David,
Thanks for the feedback.
As you probably know already, technical diversity is something the RSOs have long discussed internally, but this is the first time providing a public report. In going through the process the group discussed the right level of detail to provide and ended up settling on a high-level and simple approach that everyone could agree to for the first report.
I understand from your message that you find it lacking. I am happy to take that feedback to the group as input to the next technical diversity report that comes out.
DW
On Apr 15, 2025, at 11:41 AM, David Conrad <david.conrad@layer9.tech> wrote:
Duane,
Thanks for this. In that document, I note the following:
"Information presented here is a result of that analysis and has been aggregated across all RSOs with no attempt to convey the relative distribution of each technology."
Given this, I’m unsure of the value of this report or how exactly it helps "assure the community that the RSOs take implementation diversity seriously” (from RSSAC-001v2). Without any knowledge of the distribution of the various components mentioned, how is the community to derive any assurance that (to take absurd scenarios) all RSOs but one isn’t running (say) NetBSD, the vast majority of DNS queries aren't handled by (say) Atlas, the majority of all root server traffic isn't routed through (say) CVE-2025-21590 vulnerable JunOS, etc.
Thanks, -drc
On Apr 11, 2025, at 12:17 PM, Wessels, Duane via rssac-caucus <rssac-caucus@icann.org> wrote:
Expectation E.3.6-A of RSSAC001v2 says: The RSOs are expected to collectively publish aggregated implementation diversity reports from time-to-time.
I’m pleased to say that this has been done and you can read the report at https://secure-web.cisco.com/1kF-clvN23gJEwalfliUqIprJYpYKqLxZq4GcS1184XFE6I...
DW
_______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy ( https://secure-web.cisco.com/1-puFXaQ-M64Mow3LWDf7CwO-bcieZ94Wfgb0Mt_LEKPJuS... ) and the website Terms of Service ( https://secure-web.cisco.com/1-cMWIU8lt_xBpSjjc7WLocnAkBE8sleNAmtnbh2WpWIKm5... ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. _______________________________________________ rssac-caucus mailing list -- rssac-caucus@icann.org To unsubscribe send an email to rssac-caucus-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy ) and the website Terms of Service (https://www.icann.org/privacy/tos ). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.