ICANN ICANN Email List Archives

[comments-root-ksk-06aug15]


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

Comments on the Design Team recommendations for the Root Zone KSK Rollover

  • To: "comments-root-ksk-06aug15@xxxxxxxxx" <comments-root-ksk-06aug15@xxxxxxxxx>
  • Subject: Comments on the Design Team recommendations for the Root Zone KSK Rollover
  • From: Dan York <york@xxxxxxxx>
  • Date: Mon, 5 Oct 2015 20:58:05 +0000

ICANN Design Team,

Thank you all for the great amount of work you have devoted to developing your 
draft report on the Root Zone KSK Rollover Plan.  Overall I generally agree 
with the report and the 15 recommendations of the Design Team.  I have three 
specific concerns that I wish to raise in my comments.

1. TIMEFRAME

I continue to have a significant concern with the lack of a concrete timeframe 
for the KSK rollover to occur.  As indicated in the comments I submitted to the 
March 2013 public comment period:

http://forum.icann.org/lists/comments-root-zone-consultation-08mar13/msg00010.html

... I do believe there are serious potential operational impacts by continuing 
to delay the initial root zone KSK rollover.  The deployment of 
DNSSEC-validating resolvers is increasing each and every day.  As the overall 
level of validation increases, so too does the potential impact if 
DNSSEC-validating resolvers experience a problem and DNSSEC validation fails as 
a result of the root zone KSK rollover.  As an advocate for the deployment of 
DNSSEC, I would like to remove the uncertainty that exists around what kind of 
breakage might occur with a root zone KSK rollover so that DNSSEC deployment 
can further accelerate.

As I stated in those 2013 comments, I would like to see an ongoing routine of 
regular root zone KSK rollovers so that such events just become a normal part 
of operational routines - and also become a standard operational requirement 
for all DNSSEC-related software and services.

I do understand the technical and non-technical concerns raised by the Design 
Team in section 11 of the report, but I would encourage the Design Team, ICANN 
and the other RZM Partners to work to identify the soonest date possible when a 
rollover can occur.  On a related note, I found it puzzling that there was no 
"Next Steps" section identified in the report although I understand that the 
Design Team was asked to develop recommendations for the RZM Partners.

2. ALGORITHMS

I understand the concerns that led the Design Team to issue recommendations 7 
and 8 around cryptographic algorithms:
----
Recommendation 7: The existing algorithm and key size for the incoming KSK for 
the first Root Zone KSK rollover should be maintained.

Recommendation 8: The choice of algorithm and key size should be reviewed in 
the future, for subsequent Root Zone KSK rollovers.
----
I particularly do note the ongoing work of the Crypto Forum Research Group 
(CFRG) on new elliptic curves that could be used in DNSSEC (although I would 
note that such new algorithms, once defined, may take several more years to be 
deployed into the signing and validating software and services).

However, I do want to encourage the Design Team and the RZM Partners (ICANN, 
Verisign, US NTIA) to continue to monitor ongoing developments and to consider 
whether to address the issue of an algorithm roll should circumstances change 
between now and the time of the actual root zone KSK rollover, particularly if 
that timeframe is significantly delayed.

The smaller size of keys signed with elliptic curve algorithms can represent a 
significant performance increase and reduce some other concerns related to the 
large size of packets involved with DNSSEC.  Indeed because of these 
performance concerns we are seeing at least one large organization look at 
signing a couple of million domains with ECDSA.

I would again encourage the Design Team and RZM Partners to continue to monitor 
the deployment of DNSSEC-validating resolvers supporting ECDSA.  If the 
timeframe for a root zone KSK rollover extends out for several years I would 
encourage the Design Team and RZM Partners to consider the option of rolling 
the algorithm initially to ECDSA and then potentially in the future to a newer 
elliptic curve once appropriate levels of adoption occur.

3. COMMUNICATIONS PLAN

My largest concern is with the need for a more solid communication plan.  I 
definitely agree with Recommendation 9:
----
Recommendation 9: ICANN, in cooperation with the RZM partners, should design 
and execute a communications plan to raise awareness of the Root Zone KSK 
rollover, including outreach to the global technical community through 
appropriate technical meetings and to “channel partners” such as those 
identified in this document.
----
but section 6.5.1 of the report is very light on the details of what a 
communication plan would include.

I would encourage the Design Team and RZM Partners to seek out people from the 
communications departments of various organizations, including ICANN itself, to 
build a robust communication plan to ensure the word gets out about the 
impending root zone KSK rollover.

I cannot emphasize how CRITICAL this step is.  The success or failure of the 
root zone KSK rollover, particular this first time after the initial root zone 
signing, will largely depend upon how prepared all involved parties are for the 
various outcomes - and how much the parties are able to communicate during the 
rollover period.

On that last note, regarding Recommendation 11:
----
Recommendation 11: ICANN should coordinate with RSSAC and the RZM Partners to 
ensure that real-time communications channels are used to ensure good 
operational awareness of the root server system for each change in the Root 
Zone that involves the addition or removal of a KSK.
----
I would ask that the Design Team and RZM Partners ensure that the "real-time 
communications channels" are also available in some form OUTSIDE of just the 
RSSAC and RZM Partners.  Specifically, I would ask that such communication be 
available publicly so that a solid stream of information is available to all 
organizations that are potentially affected by the addition or removal of a KSK.


Thank you, again, to all the members of the Design Team for the work that you 
have done.  I support the 15 recommendations subject to the caveats above and 
encourage the next steps to be taken.  Specifically, I would ask ICANN and the 
other RZM Partners to proceed as soon as possible in "producing a detailed 
implementation plan for executing the first Root Zone KSK rollover" as noted in 
Section 3.

Thank you for the opportunity to comment.

Regards,
Dan York

Organizer, Internet Society DNSSEC Coordination Project
http://www.internetsociety.org/deploy360/projects/dnssec-coordination/
york@xxxxxxxx<mailto:york@xxxxxxxx>   +1-802-735-1624
Jabber: york@xxxxxxxxxxxxxxx<mailto:york@xxxxxxxxxxxxxxx>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/<http://www.internetsociety.org/deploy360/>





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

Privacy Policy | Terms of Service | Cookies Policy