On 2010-07-28, at 18:24, andrew.wallace wrote:
I think there is a social vulnerability in a group of people who need to travel, a lot of the time, by plane, to exactly the same location to make new keys to reset DNSSEC.
Let's try to forget this "reset DNSSEC" meme. This is a technical list. Let's concentrate on what we can describe accurately.
What I think is, this is leaving them wide open to attack. If an attack was state-sponsored, its likely they would be able to stop those selected people reaching the location in the United States by way of operational officers intercepting them by kidnap or murder, and indeed, a cyber attack without the need for human intervention to stop the select people getting to their destination could be done by knocking out the air traffic system. Which would, hamper the resetting and creation of new keys for DNSSEC.
The crypto officers who have generously volunteered to travel to the key management facility where they were enrolled from time to time will carry with them safety deposit box keys. As part of the process, they will unlock the safety deposit boxes contained within one of the safes in the key management facility tier 5, and extract a tamper-evident bag containing smart cards. The smart cards, under supervision of the crypto officer, are used to carry out the HSM operations that are planned for execution during that ceremony. In the event that insufficient crypto officers are able to attend (for whatever reason) ICANN retains the ability to drill the safety deposit boxes and extract the smart cards in order to preserve the security and stability of the DNS. ICANN would never do this unless the security and stability of the DNS was under threat, and would exercise this last-resort option with a great deal of public visibility. That full disclosure would unavoidably include details of people who were not able to attend. By publicising the list of crypto officers ICANN aims to increase transparency in the normal process (no drills required). We have no reason to think that our last-resort options will ever be exercised, but we have planned for them nonetheless because this is an important system and all bases need to be covered. All these details (and more) can be found in the DNSSEC Policy Statement (DPS) published at <http://www.iana.org/dnssec/>. I encourage anybody with the time and interest to dissect that document and challenge it wherever possible. Our aim is for maximum transparency and the greatest reason for the public to trust that the KSK is secure and worth trusting. One observation from a non-crypto operations guy that was drawn into this project and has learnt a lot from having to implement the infrastructure designed by real crypto people: security is not always obvious. What seems like a flaw is often not, and what seems safe is often risky. There is a great deal to learn about security engineering, and what seems obvious is frequently not. Joe