Web expert on his 'catastrophe' key for the internet

Franck Martin franck at genius.com
Fri Jul 30 03:23:25 UTC 2010


Hmmm, from the interview of the British guy, the smart card seems to be in UK (he did a lapsus on it), which differs from what you describe.

if all the smart cards are in the US in an individual safe deposit box in the same location, this raise the concern that there is only one place the smartcard can be stolen or destroyed.

Also, is it part of the process that each smart card holder must routinely check that "his" smartcard is still there?

I would have also thought, that there would be redundancy into these smartcards, like you need 3 out of 5 to rebuild the key, or something like this.

I should read the spec....

Usually IETF people are well versed on security, so I believe the process to be quite sound.

----- Original Message -----
From: "Joe Abley" <jabley at hopcount.ca>
To: "andrew.wallace" <andrew.wallace at rocketmail.com>
Cc: nanog at nanog.org
Sent: Friday, 30 July, 2010 10:48:40 AM
Subject: Re: Web expert on his 'catastrophe' key for the internet


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




More information about the NANOG mailing list