ICANN/GNSO GNSO Email List Archives

[ispcp]


<<< Chronological Index >>>    <<< Thread Index >>>

[ispcp] Fwd: [dssa] Requesting Public Comments

  • To: "ispcp@xxxxxxxxx" <ispcp@xxxxxxxxx>
  • Subject: [ispcp] Fwd: [dssa] Requesting Public Comments
  • From: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Date: Thu, 27 Sep 2012 11:00:03 -0500
  • List-id: ispcp@xxxxxxxxxxxxxx
  • References: <574A3685-AC4E-4DB9-A096-FD2ABC9EBD54@haven2.com>
  • Sender: owner-ispcp@xxxxxxxxxxxxxx

hi all,

now that i've to ally confused everybody with my apology for missing a call that doesn't exist, let me add further to your workload.

we, the DSSA (DNS Security and Stability Advisory working group) would really benefit from some public comments on our report.  since i'm a co-chair of the working group, and pretty much wrote the whole report, i'm reluctant to be the rapporteur for us on on this one.  but it turns out that lots of people in the working group must have felt the same way and the result is that we got ZERO public comments.  zip.  nada.  nothing.

so we're fanning out to our respective constituencies and asking that they try to get something submitted during the "reply" comments period, which ends just after Toronto.  here's a little note that i sent out to the WG.  could i impose on some of you to craft something?

sorry to bother you twice in one day, but this one is actually fairly important.  one important aspect of this is to get a feeling for whether this cross-constituency group is actually working well, because it might be a good model for others.  but it's hard to hold it up as a model if there aren't any reactions to the work that it did.  :-)

thanks,

mikey

Begin forwarded message:

> From: "Mike O'Connor" <mike@xxxxxxxxxx>
> Subject: [dssa] Requesting Public Comments
> Date: September 27, 2012 10:20:43 AM CDT
> To: DSSA WG <dssa@xxxxxxxxx>
> 
> 
> Hi all,
> 
> Just a note to highlight that it would be extremely helpful if your respective constituencies and supporting organizations could contribute public comments regarding the work of the DSSA so far.  The initial public comment period is closed and the reply-period is going to close just after the Toronto meeting, so time is drawing short.  Especially given that we'd like to review those comments *during* the Toronto meeting.
> 
> Here are a few points to consider when you lobby your respective organizations:
> 
> -- The comments don't necessarily need to be long.  A simple "the DSSA is doing fine" would suffice in a pinch, although some words explaining why would be helpful.  Since the DSSA is one of those cross-community working groups, we could use some guidance as to whether we're doing that work in a way that is satisfactory.
> 
> -- The DSSA made some fairly interesting observations in its Phase 1 Report and it would be good to get a sense from your respective organizations as to whether we're on the right track.  I've included the picture-book Executive Summary in this post to remind you of the high spots.  Again, "you're doing fine" is an acceptable response although again a few words of support would be welcome.  
> 
> And of course the most important comments are those that take issue with something we've done -- we will listen to those and try to set ourselves on the right track.
> 
> Here's a link to the Public Comment Forum for our work.  Please encourage your membership to contribute.
> 
> 	http://www.icann.org/en/news/public-comment/dssa-phase-1-report-14aug12-en.htm
> 
> Thanks,
> 
> Mikey
> 
> 1. Executive Summary
> 
> This is the first of two reports from the DNS Security and Stability Analysis working group.   The goal of this document is to bring forward the substantial work that has been completed to date and describe the work that remains. 
> 
> This has been in many respects a “pioneering” cross-constituency security-assessment effort that has developed knowledge and processes that others will hopefully find helpful and can be reused in the future.
> 
> The DSSA has:
> Established a cross-constituency working group and put the organizational framework to manage that group in place
> Clarified the system, organizational and functional scope of the effort
> Developed an approach to handling confidential information, should such information be required for certain assessments
> Selected and tailored a risk-assessment methodology to structure the work
> Developed and tested mechanisms to rapidly collect and consolidate risk-assessment scenarios across a broad and diverse group of interested participants
> Used an “alpha-test” of those systems to develop the high-level risk-scenarios in this report.  Those scenarios will serve as the starting point for the remainder of the effort
> 
> Work that remains:
> Perform a proof of concept to refine and streamline the methodology on one broad risk-scenario topic with the goal of reducing cycle time and making it more accessible to a broader community
> Roll the methodology out to progressively broader groups of participants to introduce the methodology to the community and further improve the process and tools on the way to completing the assessment
> 
> 1.1. Key findings
> 
> The DSSA has a number of observations to share with the community after completing the first phase of its work.  Those observations are summarized here, presented in more detail in the body of this report and in some cases presented in even more detail in the Appendix.   The working group has also developed a series of tools that can be used by any DNS provider to conduct risk assessments.  Those tools, and extremely detailed documentation of the assessment, are available on the working group wiki.
> 
> 1.1.1. Risk Scenarios
> 
> The DSSA has analyzed five broad risk scenarios.  These will be explored in more depth during the next phase of the effort.  Those scenarios are:
> Gaps in policy, management, or leadership lead to splitting the root
> “Reductive” forces (security, risk-mitigation, control through rules, etc.) lead to splitting the root
> Widespread natural disaster brings down the root or a major TLD
> Attacks exploiting technical vulnerabilities of the DNS bring down the root or a major TLD
> Inadvertent technical mishap brings down the root or a major TLD
> 
> 1.1.2. Scope
> 
> The DSSA analyzed several scope issues that needed to be resolved in order to complete the work. 
> Scope of “the DNS” used by the working group
> The functional context of the DSSA within a broader risk management framework
> The organizational context of the DSSA vis a vis the SSR-RT and DNRMF efforts
> 
> 1.1.3. Approach
> 
> The DSSA also embarked on developing methodologies that were required in order for the working group to complete its assignments.  These methods may be useful in other contexts, both inside and outside of ICANN.   These include:
> A protocol for handling confidential information
> A tailored “compound sentence” risk-assessment methodology based on the NIST 800-30 and 800-53 standards
> An approach to risk assessment that accommodates the unique security assessment requirements of the multi-stakeholder DNS ecosystem
> 
> 1.1.4. Remaining work
> The DSSA realized that a detailed assessment of the risk scenarios it has identified is likely to take a substantial amount of time.   The DSSA, after consultation with its chartering ACs and SOs, broke its work into two phases.  This report summarizes the work to date, while the next phase will:
> Take that work to a more detailed level,
> Refine the approach and methods developed so far, and
> Explore whether it is feasible to transition this one-time effort into an ongoing function to maintain an up to date assessment of DNS risk.
> 
> 
> 
> 
> - - - - - - - - -
> phone 	651-647-6109  
> fax  		866-280-2356  
> web 	http://www.haven2.com
> handle	OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)
> 

- - - - - - - - -
phone 	651-647-6109  
fax  		866-280-2356  
web 	http://www.haven2.com
handle	OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)



<<< Chronological Index >>>    <<< Thread Index >>>