Feedback from BII on DNS Root Zone KSK Change
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.