Re: towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
There are a lot of work going on in this area, including how to use secure DNS to associate the key that appears in a TLS server's certificate with the the intended domain name [1]. Adding HSTS to this mix does make sense and is something that is discussed, e.g. on the keyassure mailing list [2]. jakob [1] http://tools.ietf.org/html/draft-hoffman-keys-linkage-from-dns-00 [2] http://www.ietf.org/mailman/listinfo/keyassure - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
On 2 aug 2010, at 08.30, Peter Gutmann wrote: > For the case of DNSSEC, what would happen if the key was lost? There'd be a > bit of turmoil as a new key appeared and maybe some egg-on-face at ICANN, but > it's not like commercial PKI with certs with 40-year lifetimes hardcoded into > every browser on the planet is it? Presumably there's some mechanism for > getting the root (pubic) key distributed to existing implementations, could > this be used to roll over the root or is it still a manual config process for > each server/resolver? How *is* the bootstrap actually done, presumably you > need to go from "no certs in resolvers" to "certs in resolvers" through some > mechanism. Initial bootstrap is done by - distribution of the key by ICANN (via http://data.iana.org/root-anchors/) - distribution of the key by the vendors themselves Authentication of the root key can be achieved as part of the the distribution mechanisms above, or by transitive trust through people who attended the key generation ceremony. We've already seen public attestations from participants (e.g., [1], [2] and [3]). Key rollovers are performed as specified in RFC 5011, i.e. a new key is authenticated by the current key. This does of course not work when the existing private key material is inaccessible (on form of "lost"). It could work if the key is "lost" by compromise, but one has to take into consideration how the key was compromised in such cases (key misuse, crypto analysis, etc). For the generic end user, I would expect vendors to ship the root key as part of their software and keep the key up to date using their normal software update scheme. jakob [1] http://www.kirei.se/en/2010/06/20/root-ksk/ [2] http://www.trend-watcher.org/archives/dnssec-root-key-declaration/ [3] http://www.ask-mrdns.com/2010/07/root-dnssec-key-attestation/ - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
On 2 aug 2010, at 16.51, Jeffrey Schiller wrote: > Does the root KSK exist in a form that doesn't require the HSM to > re-join, or more to the point if the manufacturer of the HSM fails, is > it possible to re-join the key and load it into a different vendor's > HSM? With the assistance of the vendor (or their employees), it would be possible to reassemble the storage master key (SMK) by combining 5 of 7 key shares, then decrypting the key backup. There is nothing in the HSM units itself that is needed for a key restore. > In other words, is the value that is split the "raw" key, or is it in > some proprietary format or encrypted in some vendor internal key? The value that is split is the SMK, used to encrypt the actual key. The actual key is not split and, once in production, is never to be transported outside the ICANN Key Management Facility. > Back in the day we used an RSA SafeKeyper to store the IPRA key (there > is a bit of history, we even had a key ceremony with Vint Cerf in > attendance). This was the early to mid '90s. Aha, that's why Vint was so on top of things during the East Coast key ceremony :-) > The SafeKeyper had an internal tamper key that was used to encrypt all > exported backups (in addition to the threshold secrets required). If > the box failed, you could order one with the same internal tamper > key. However you could not obtain the tamper key and you therefore > could not choose to switch HSM vendors. In this case, the SMK == the tamper key. jakob - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
On 1 aug 2010, at 16.43, Thierry Moreau wrote: > Technically, the USG requested FIPS-140-2 level 4 HSM technology for the DNS > root signing gear. This implies a single source, with a very inflexible user > interface (no special personalization of the HSM for the DNSSEC project). The > threshold scheme was present in the vendor offering but there was no > documented use of it (it may have been used internally by some organizations > that would have taken seriously the dual control principle but who knows). I'm not sure what you mean with "no documented use of it" and I'm not sure why there is a need to add any FUD on this matter. If you have any questions or doubt regarding the m-of-n implementation and its use, I'm sure we can get the appropriate answers from the vendor. > I don't know whether a number-theoretic foundation lies behind the threshold > scheme. In any event, the crypto value protected by the scheme is the long > term (intergity-)encryption key for the HSM configuration file, which > includes the DNSSEC KSK private key. The storage master key (SMK) used for key backup is protected by a 5 of 7 scheme. The activation key for the HSM key material (aka AAK) is protected by a 3 of 7 scheme. This is all documented in the DPS. > The detailed usage (the HSM is FIPS-approved, the usage is outside of > compliance scope) is also documented (as usual you have to infer the > operating principles from a plethora of minute details and meaningless > acronyms). I made a critique of it on this list recently. Outside of this > critique is the (inconsequential) fact that they seem to use "1234" as the > PIN for the smart cards (I got this fact from a glimpse at the real-time > video of the key ceremony). There is no PIN for the SMK shares. The is a PIN for the AAK share, but as we have other security controls to manage the risks that the PIN would mitigate (remembering that the PIN itself introduces some issues as well), we choose to not use it (or rather; use a fixed, known PIN). > One is the backup for long-term recovery capability. They rely on 5-of-7 > custodians spread across a few continents (ICANN needs to look like an > international organization). > > The other purpose was transient, for the duplication of signature capability > from the "East coast facility" to the "West coast facility". In that case, > they use something like 2-of-3 (or 2-of-4) but they shipped the key share > media (smart cards) and the HSM configuration file (yes, it *WAS* encrypted!! > ) by means not subject to the same control/audit scrutiny as the rest of the > procedure. The above is actually the same very SMK, but the 2nd copy of the SMK shares (the one used for transporting the key material from the east to the west coast) was destroyed as part of the ceremony at the west coast (where the key from the east coast where restored). The 2nd copy of the SMK was generated using a 2 of 4 scheme. The couriered key material was indeed under the same control/audit scrutiny as the rest of the procedures, is was documented both in writing and by video. Anyone in doubt of what happened, how data was transported and what controls were in place to detect tampering and/or other threats, are more than welcome to contact me and I will try to answer any questions. > With the next key generation for DNS root KSK signature key, ICANN may have > an opportunity to improve their procedure. However, at this point the project > will be the focus of less attention, and the institutional commitment may not > be as strong as it was for the first key generation. We'd be happy to learn from your experience in this matter and will listen carefully to any feedback from the community. But before submitting comments, I do urge people to review the key ceremonies that took place on the east and west coast (audit material is available online at http://data.iana.org/ksk-ceremony/). jakob - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Is this the first ever practically-deployed use of a threshold scheme?
On 31 jul 2010, at 08.44, Peter Gutmann wrote: > Apparently the DNS root key is protected by what sounds like a five-of-seven > threshold scheme, but the description is a bit unclear. Does anyone know > more? The DNS root key is stored in HSMs. The key backups (maintained by ICANN) are encrypted with a storage master key (SMK), created inside the HSM and then split among 7 people (aka "Recovery Key Share Holders"). To recover the SMK in case of all 4 HSMs going bad, 5 of 7 key shares are required. (https://www.iana.org/dnssec/icann-dps.txt section 5.2.4) According to the FIPS 140-2 Security Policy of the HSM, an AEP Keyper, the M-of-N key split is done using a La Grange interpolating Polynomial. I'd be happy to answer any additional questions, jakob (part of the team who designed and implemented this) - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
Re: Root Zone DNSSEC Deployment Technical Status Update
On 16 jul 2010, at 19.59, Thierry Moreau wrote:
> With what was called DURZ (Deliberately Unvalidatable Root Zone), you,
> security experts, has been trained to accept signature validation failures as
> false alarms by experts from reputable institutions.
Thierry, do you know of anyone that configured the DURZ DNSKEY and accepted the
signature validation failure resulting because of this? We had good
(documented) reasons for deploying the DURZ as we did, the deployment was
successful and it is now all water under the bridge. Adding FUD at this time
does not help.
> Auditing details are not yet public.
Yes, they are - see http://data.iana.org/ksk-ceremony/. If there is anything
missing, please let me know.
> I am wondering specifically about the protections of the private key material
> between the first "key ceremony" and the second one. I didn't investigate
> these details since ICANN was in charge and promised full transparency.
> Moreover, my critiques were kind of counterproductive in face of the
> seemingly overwhelming confidence in advice from the Verisign experts. In the
> worse scenario, we would already have a KSK signature key on which a
> "suspected breach" qualification would be attached.
The key material was couriered between the Key Management Facilities by ICANN
staff members. I'd be happy to make sure you get answers to any questions you
may have regarding this handling.
> Is there an emergency KSK rollover strategy?
Yes, please read the DPS - https://www.iana.org/dnssec/icann-dps.txt.
jakob (member of the Root DNSSEC Design Team)
--
Jakob Schlyter
Kirei AB - http://www.kirei.se/
-
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
