March 2019 - Ssr2-review - lists.icann.org

New clarification request
by Jennifer Bryce April 1, 2019

April 1, 2019

Dear all, Please see below for a new clarification request, and the 5 outstanding requests for clarification on questions asked to ICANN org. New request: Review Team volunteers: Boban, Alain, Žarko Workstream: ICANN SSR Topic 2: Perform an assessment of ICANN's Business Continuity Management System. Clarification requested: What is meant by “inter-org” dependencies? Which orgs? What is meant by “boundaries.” 1. Does ICANN have documented boundaries and processes that have inter-org dependencies? Do they relate back to BC plans? Outstanding requests: Review Team volunteers: Scott, Noorul Workstream: ICANN SSR Topic 4: Perform an assessment of how effectively ICANN has implemented its Security Incident Management and Response Processes to reduce (pro-active and reactive) the probability of DNS-related incidents. Clarification requested: Can you please clarify if these questions are specific to the ICANN Managed Root Server or more generally for ICANN? 1. Which certifications is ICANN pursuing for the organisation and staff? 2. Which certifications and compliance frameworks has ICANN completed? 3. Who are ICANN’s auditors, what audits are completed regularly? Review Team volunteers: Eric, Denise, Norm, Boban Workstream: Future Challenges Topic: Coalescence of registrars/registry/backend operators for multiple TLDs Clarification requested: Can you please provide further context behind the question or clarify the question? 1. Has ICANN identified the issue of coalescence of registrars/registry operators in their risk management and what are the measures be taken? 2. Are there any and if so, what are the control mechanisms for operational availability of the TLD’s? Best, Jennifer -- Jennifer Bryce Senior Reviews Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Email: jennifer.bryce(a)icann.org Skype: jennifer.bryce.icann www.icann.org

2 1

SSR2 action for 4 April
by Jennifer Bryce March 29, 2019

March 29, 2019

Dear SSR2 RT members, As discussed on the plenary call yesterday, please check the work topics that your name is against in the volunteers doc here<https://docs.google.com/document/d/1nmPIw-Q6nKI4UdQjAz4KAH83jMU2TIJWncZroWE…>, and continue to coordinate the work with other volunteers in the topic. Please be ready to provide an update on your topics on the plenary call next week (4 April). Best, Jennifer -- Jennifer Bryce Senior Reviews Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Email: jennifer.bryce(a)icann.org Skype: jennifer.bryce.icann www.icann.org

1 0

Call summary: SSR2 28 Mar
by Jennifer Bryce March 29, 2019

March 29, 2019

Dear SSR2 RT members, Please find attached the plenary call report for SSR2 meeting #64, 28 March at 15:00 UTC. These high-level notes are designed to help SSR2 Review Team members navigate through the content of the call. They are not meant to be a substitute for the recording or transcript, which are posted on the wiki at: https://community.icann.org/x/ugtIBg. The transcript usually becomes available 5 - 7 business days after the meeting. Best, Jennifer -- Jennifer Bryce Senior Reviews Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Email: jennifer.bryce(a)icann.org Skype: jennifer.bryce.icann www.icann.org

1 0

Future Challenges answers
by Jennifer Bryce March 28, 2019

March 28, 2019

Dear SSR2 RT, Please see below for the answers to 3 questions in the Future Challenges workstream. The answers have been added to the Q&A Google doc: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7… [docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_docume…>. Please let us know if you have any questions. Review Team volunteers: Eric, Norm, Laurin Workstream: Future Challenges Topic: Alternate naming systems (interactions, conflicts, etc). Blockchain, e.g. Namecoin, ENS, etc., Other DNS-less systems, walled gardens? Censoring Outstanding questions: 0 Q: Does ICANN track these developments, what are the findings, and how do they feed into ICANN operations and policy? A: We track these emerging identifiers internally and regularly organize session at ICANN meetings to present them to the community for input and if needed launch policy discussion by the community via defined process. Here are the archives of past sessions: ICAN58 - https://sched.co/9nqD [sched.co]<https://urldefense.proofpoint.com/v2/url?u=https-3A__sched.co_9nqD&d=DwMFaQ…> ICANN60 - https://sched.co/CbFe [sched.co]<https://urldefense.proofpoint.com/v2/url?u=https-3A__sched.co_CbFe&d=DwMFaQ…> ICANN64 - https://64.schedule.icann.org/meetings/961998 [64.schedule.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__64.schedule.icann.org_…> ICANN org does not suggest policy nor do we anticipate what the community will find important to run through their policy development processes. Our role is mainly to a) identify technologies that are emerging and raise comment in various circles, b) expose them to the ICANN community; and if required by them c) proceed with further study of the technology and determine if any impact to the org. DOA is one of the naming systems that had much traction in the community and following these EI sessions the Research team has worked on a white paper that studies in depth the technology and architecture behind DOA. The paper is under peer review and will be published soon. In addition to that the OCTO team has written several Internal technical briefings on emerging technology to the Board. Work is underway to publish some of these briefings for community consumption. Review Team volunteers: Russ, Eric, Ram, Laurin, Alain Workstream: Future Challenges Topic: New crypto systems in DNSSEC Outstanding questions: 0 Q: Does the TEG or some other group provide information about new crypto algorithms? Where? A: There is no specific group that handles crypto algorithms. Crypto algorithms are discussed in many other security forums other than ICANN. In general the OCTO team monitor development of new technology in general including crypto. In case anything comes up as critical, the OCTO team will certainly raise it with the Board, the BTC and probably the TEG. Review Team volunteers: Noorul, Kerry-Ann, Eric, Norm, Laurin Workstream: Future Challenges Topic: Root server system protection: assess the threatscape of top threats (e.g. DDoS to the root system) Outstanding questions: 1 Q: Was the threatscape documented and shared with the community/RSOs? A: No -- Jennifer Bryce Senior Reviews Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Email: jennifer.bryce(a)icann.org Skype: jennifer.bryce.icann www.icann.org

1 0

SSR2 agenda: 28 March
by Jennifer Bryce March 28, 2019

March 28, 2019

Dear all, Please see below for the agenda the SSR2 plenary call today at 14:00 UTC. 1. Welcome, roll call, SOIs * Brussels meeting: RT members to let staff know if they have visa requirements, any other questions. 2. Updates from staff: * Technical writer * Answers from staff on outstanding questions 3. Team update on drafting recommendations and report text * Volunteers doc here: https://docs.google.com/document/d/1nmPIw-Q6nKI4UdQjAz4KAH83jMU2TIJWncZroWE… * Q&As doc here: https://docs.google.com/document/u/1/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JY… 4. AOB 5. Confirm action items, decisions reached Best, Jennifer -- Jennifer Bryce Senior Reviews Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Email: jennifer.bryce(a)icann.org Skype: jennifer.bryce.icann www.icann.org

1 0

DNS SSR answers
by Jennifer Bryce March 27, 2019

March 27, 2019

Dear Boban, Laurin and Žarko, Please see below for the answers to 5 questions in the DNS SSR workstream, re: TLD label management, root zone change management, and NS/DS record management. With these answers, there are no outstanding questions in each of these topics. The answers have been added to the Q&A Google doc: https://docs.google.com/document/d/14eJwDGP-LvS9ltTmZoh1i19Fi0_pB2nJ4JYMsS7…. Please let us know if you have any questions. Review Team volunteers: Boban, Laurin, Žarko Workstream: DNS SSR Topic: TLD Label Management Outstanding questions: 0 Q: What technologies are used to ensure integrity and authentication? A: We understand this question relates to a TLD operator managing their label in the root zone. If this is referring to something else, please advise. We operate a custom workflow system for managing TLD labels in the root zone called the Root Zone Management System (RZMS). Authentication of customer users to the RZMS is performed by username and password, using randomized usernames that are issued by IANA, and passwords that need to meet minimum complexity requirements. Access to privileged users (such as staff) is via an entirely different host, which in addition to username and password access requires through the company VPN and active privileges on the company-wide Active Directory service. Access to the VPN requires multi-factor authentication. It is worth noting that customer use of RZMS in the current trust model is a convenience that does not provide additional privileges beyond that of an anonymous customer. It provides a convenient access to submit change request, review pending and historical change requests, and withdraw change requests in a self-service manner, but access is not required to perform these functions. The ability to submit and authorize a change request is possible via historical methods (such as email or fax) and does not require access privileges to RZMS. The IANA team is currently building its next generation RZMS system which involves a substantial rewrite of the authorization model. The plans we have shared with our user community involve moving to a model where authentication is made a requirement for lodgment of routine change requests and to provide authorization by authorizing users. (The policy is such that third parties have standing to submit change requests, such as in the case of a transfer request, so that will still be available. In addition, we plan to retain the flexibility to receive out-of-band requests to stay nimble in response to emergency scenarios where connectivity may be limited.) Q: What procedures are used to address SSR concerns when it comes to TLD label management? A: In general, an extremely conservative approach is taken to managing the root zone in recognition of its critical role in the DNS ecosystem, which supports our objectives for security, stability and resiliency. In terms of the general operational workflow, processing follows a well-understood process that involves significant review of each change by multiple parties. Automated testing of changes is performed by two independent entities (PTI as the Root Zone Manager, and Verisign as the Root Zone Maintainer). Key management for the root zone is similarly split (PTI as the Root KSK Operator, and Verisign as the Root ZSK Operator). All changes are manually reviewed throughout the process, and staff are empowered to ask questions and engage with the customer whenever a request raises a concern prior to implementation. Evolutionary activities have been accompanied by highly conservative approaches. Implementation of our automation systems have been accompanied by extended periods of 'parallel testing', where existing and future operations are run in parallel for an extended period (e.g. 90 days) to ensure there are no regressions before the new system becomes primary. Growth of the root zone during the last gTLD round was limited to a rate of 20/week (i.e. 1,000/year) to ensure operations could be measured for deleterious effects. The initial signing of the root zone with DNSSEC, and the recent first KSK rollover, used techniques such as the Deliberately Unvalidatable Root Zone, and phased approaches that involved monitoring key transitions and fallback Key Signing Responses allowing quick restoration of prior state if needed. Institutionally, there are multiple ICANN committees that provide recommendations and review of the operational environment. The Customer Standing Committee conducts performance related oversight. The Root Zone Evolution Review Committee reviews any architectural changes to the root zone. The relevant Supporting Organizations develop applicable policy that governs what may be delegated in the root zone, and the SSAC and RSSAC also have responsibility for facets of the system. Review Team volunteers: Laurin, Boban, Žarko Workstream: DNS SSR Topic: Root Zone Change Management (Verification, etc.) Outstanding questions: 0 Q: What technologies are used to verify requests? A: There are two primary techniques used to verify requests: obtaining authorization/consent from the nominated representatives of the TLDs upon receipt of a request, and performing a set of technical checks for the technical attributes of a TLD's delegation. As noted earlier, the submission of a change request is not limited to specific parties but is possible by anyone. Proceeding with a change request is not dependent on who submitted it, but an analysis that the change request comports with relevant policies and procedures, including consent from representatives of the TLD manager. Changes to the technical delegation data that appears in the root zone (i.e. NS records, DS records, and associated glue records) requires that the change be reflected in the child zone prior to being proposed for the root zone. Part of the checking is to ensure NS changes reflect changes implemented in the apex of the TLD zone, that DS records have matching DNSKEYs in the apex of the TLD zone, and the authoritative zone for glue records reflects the addresses proposed as glue in the root zone. This testing is performed by two independent implementations (one by PTI, one by Verisign). In addition, for gTLD delegations, it is tested by a third independent implementation (as part of pre-delegation testing during the gTLD's evaluation prior to delegate, independent of the root zone change process.) Q: How are actors verified when changes to the root zone are requested / undertaken? Are there procedures, and where can they be found? A: In the current model, a nonce is sent via email to the two contacts for the domain and both must use to approve or reject the change request. Contacts can nominate a private email address that does not appear in the WHOIS for this purpose. See https://www.iana.org/help/obtaining-consent Note the requirement described above that changes must have also been enacted in the child zone. Help documentation that covers the basic workflow, technical requirements and other aspects is at https://www.iana.org/domains/root/help Review Team volunteers: Boban, Laurin, Žarko Workstream: DNS SSR Topic: NS/DS Record Management Outstanding questions: 0 Q: How are actors verified by IANA when any changes to the root zone are requested / undertaken? (For example, what happens if TLD op requests IP change of authoritative server?) * Are there procedures, and where can they be found? * What technologies are used to verify requests? * What procedures are used to address SSR concerns when it comes to NS/DS record management inside the root zone? * What technologies are used to ensure integrity and authentication when it comes to NS/DS record management inside the root zone? * What are the provisions and procedures for emergency changes and emergency rollbacks in/to the root zone? A: These seem to be the same questions just restated in a different way, except for one, “What are the provisions and procedures for emergency changes and emergency rollbacks in/to the root zone?” Both PTI and Verisign maintain 24x7 capabilities to respond and process emergency changes to the root zone. TLD managers are given an escalation call center number to signal an emergency. Generally, they are asked to submit their change request, if they are able, via the RZMS, and then call the call center to escalate the request. Upon receipt of an emergency escalation, IANA staff will discuss the nature of the emergency with the customer to ensure it requires that level of response. Assuming that is so, Verisign will be activated to be ready to implement the root zone outside their normal schedule. IANA processes the change request on an expedited schedule according to normal procedures, and transmits the request to Verisign with an emergency flag set. Verisign will typically issue an expedited root zone earlier than their typical daily publication schedule. There is no provision for "emergency rollbacks" of root zone changes. Any changes to the root zone to reverse the effect of a prior change would be by issuing a subsequent new root zone with the record changes unwound, but not rolling back to a previous version of the root zone. TLD managers who wished to reverse the effects of an implemented change would submit a new change request requesting changes with the new configuration they desire. -- Jennifer Bryce Senior Reviews Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Email: jennifer.bryce(a)icann.org Skype: jennifer.bryce.icann www.icann.org

1 0

SSR2-RT Face to Face - Day 2 | 18 May 2019
by Danko Jevtovic March 27, 2019

March 27, 2019

Dear Russ, team, Unfortunately I won’t be able to join you for the f2f meeting in Brussels. I have previously fixed teaching engagement in a business school in Belgrade on May 18th. I will participate remotely on other days. I am looking forward to the call tomorrow. Best, Danko Jevtović ICANN Board of Directors member <mailto:danko.jevtovic@board.icann.org> danko.jevtovic(a)board.icann.org <https://www.icann.org/resources/pages/board-of-directors> www.icann.org <http://fb.com/dankoj> fb.com/dankoj <https://www.linkedin.com/in/dankoj> linkedin.com/in/dankoj <http://twitter.com/dankoj> twitter.com/dankoj Skype: <callto:dankoj> callto:dankoj mobile: +381-65-3496666

1 0

Clarification request: ICANN SSR questions
by Jennifer Bryce March 26, 2019

March 26, 2019

Dear SSR2 RT, Some clarifications have been requested from ICANN org on the below questions. Could the volunteers for each topic please provide the requested clarifications? Review Team volunteers: Scott, Noorul Workstream: ICANN SSR Topic 4: Perform an assessment of how effectively ICANN has implemented its Security Incident Management and Response Processes to reduce (pro-active and reactive) the probability of DNS-related incidents. Clarification requested: Can you please clarify if these questions are specific to the ICANN Managed Root Server or more generally for ICANN? 1. Which certifications is ICANN pursuing for the organisation and staff? 2. Which certifications and compliance frameworks has ICANN completed? 3. Who are ICANN’s auditors, what audits are completed regularly? Review Team volunteers: Eric, Denise, Norm, Boban Workstream: Future Challenges Topic: Coalescence of registrars/registry/backend operators for multiple TLDs Clarification requested: Can you please provide further context behind the question or clarify the question? 1. Has ICANN identified the issue of coalescence of registrars/registry operators in their risk management and what are the measures be taken? 2. Are there any and if so, what are the control mechanisms for operational availability of the TLD’s? Thanks, Jennifer -- Jennifer Bryce Senior Reviews Coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Email: jennifer.bryce(a)icann.org Skype: jennifer.bryce.icann www.icann.org

1 0

Minimum Required Information for Whois Data Requests by Registrar Stakeholder Group
by Barrett, Kerry-Ann March 25, 2019

March 25, 2019

FYI The RrSG has published a document representing the minimum requirements for Registrars to respond to data disclosure requests for registration data. You may download this document here: http://icannregistrars.org/wp-content/uploads/2019/02/RrSG-Minimum-Required…

1 0

Re: [Ssr2-review] SSR > Meeting #41 - 25 March 2019
by Russ Housley March 21, 2019

March 21, 2019

Regrets. I will be at the IETF meeting. Russ

1 0