Feedback from BII on DNS Root Zone KSK Change

[Shane Kerr <shane@xxxxxxxxxxx>]

All,

Attached please find some feedback from Davey Song and myself about the
DNS Root Zone KSK Change plan.

Cheers,

--
Shane

Issue 1
=======
ICANN should propose research or survey the community for novel
approaches. We can make a plan  and follow the current practice with
conservative estimate, but further exploration may provide more
evidence on alternate approaches.

For example: 
  On the resolver side: RFC5011 support, EDNS0 support, TCP fallback
  In the authority side:  larger response sizes (if the 512 octet
     limit still observed in current network, or IPv6 impact


Issue 2
=======
The proposed key rollover process seems both novel and complicated.

* It uses a key rollover procedure that is unlike any other that has
  ever been used.

* This procedure involves extra steps and careful timing.

For such an important thing as rolling the root zone, these are
undesirable properties.

These procedures are motivated by two things:

1. Concern over the impact of large packet sizes
2. Need to adhere to the schedule laid out in the DPS

Concern Over Packet Size
------------------------
The measurements presented in the proposal indicate that 0.04% of all
users would be impacted by large packet sizes, although the
uncertainty is great and it could be up to 1% of all users. The plan
also notes that the .org zone has had larger keys than 1500 bytes
without any negative impact.

As the plan mentions, the only ones that would be affected by problems
delivering packets are those behind validating resolvers. The likely
case is that this is a small fraction of those affected.

While it would be an epic failure to disable DNS for 1% of users of
the Internet, this does not seem like a likely scenario. Much more
likely is that large packets would affect something like 0.01% of
users.

Partially in order to insure that packet sizes are kept to an absolute
minimum, a KSK roll procedure has been proposed that is not the same
as the double-DS KSK roll procedure outlined in RFC 6781. While this
may work, it seems far riskier than impacting 0.01% of users.

Adherence to the DPS
--------------------
The DPS defines how the KSK is managed. This has many benefits, such
as insuring that the process can be audited by security experts,
compared with DPS used by other zones, and so on.

In the case of the root zone KSK roll, the DPS has two negative
impacts when combined with the fear of large packets:

1. The KSK roll takes a very long time
2. There is the extremely strange approach of RE-INTRODUCING the old
   KSK in order to mark it revoked


Possible Alternate Approach
---------------------------
The simplest approach might be best, which would be to simply use the
double-DS KSK roll procedure (minus the DS change, since the root has
no parent):

1. Generate a new KSK. Publish it.
2. Wait X days.
3. Set the "revoked" flag on the old KSK. Replace the old KSK in the
   root zone with this version. Sign ZSK with the old and the new KSK.
4. Wait X days.
5. Remove the old KSK.

X must be at least 30, due to the RFC 5011 "hold down timer". It can
be exactly 30 to roll the KSK as quickly as possible, or some greater
amount to allow administrators more time to change their setup.


Also, one could optionally change the DPS to allow the ZSK to stay the
same while a KSK roll is in process. This would reduce the worst-case
size of packets in the reply for DNSKEY lookups.



Validating KSK Roll Approaches
------------------------------
We should test the KSK roll approach in a testbed that looks similar
to the production environment. This includes both lab tests, and
larger testbeds such as Yeti. This is true whether the approach
presented in the KSK rollover plan is used or some other approach.