(I mentioned this to mgoodwin in the #security channel on irc.mozilla.org, and he suggested I bring it here.)
Waking from the Email Key Management Nightmare (or, Solving the Message Accessibility After Hardware Death Problem) (and, Solving the Key Distribution Problem Without Trent's Directory) Currently, encrypted email messages are tied to asymmetric keys. In general, non-exportable asymmetric keys are preferable to exportable ones (specifically, NSS will not mark a key as non-exportable if it imported it, and we also know that asymmetric private keys are as valuable as their certifications). So, this means that if we adhere to good key management practices, access to our encrypted mail messages from whatever time period is tied directly to hardware availability. Losing access to entire timespans of data is a problem for both individuals and corporate entities, so we need to solve it if we can. It turns out that the real management issue is not the asymmetric keys. We need to manage the per-message symmetric keys, the things that we actually need to have to gain access to the messages, instead. These can be managed separately from the asymmetric keys that they are originally encrypted to, perhaps by re-encrypting them to other asymmetric keys held by the same person and designated for "hardware failure recovery" or "another device which needs to have access to the user's mail". (The processing for both types of message recovery needs to happen at the same time (as part of the same on-message-receipt flow). Because not having access to mail on multiple terminals is also a problem with current S/MIME (and I daresay PGP), we should solve it if we can.) We could make our signing and encryption keys for S/MIME be different (as they typically are today), with the signature key nonexportable and the encryption key exportable. This causes problems based on the idea that if the encryption key is stolen (much more likely with an exportable key than a nonexportable key), all messages sent to that key including all future messages are compromised. Even if the per-message symkeys were stored unencrypted separately in a database, then one-time compromise of that database would still provide perfect forward secrecy for all future messages. To solve the problem of asymmetric key distribution without Trent's Directory, we need to do a TLS-like communication between two email addresses. The message flow: 1) Alice sends Bob "hello, I'd like to talk with you" plaintext which also contains a public key. 2) Bob sends Alice "here's a public key you can use for me, now who are you?" ciphertext under a symkey chosen by Bob and encrypted to Step1PublicKey. 3) Alice decrypts "who are you?", then sends Bob "Alice's actual message" containing AliceCertificateChain and Step1PublicKey, signed with both AliceCertifiedKey and Step1PublicKey, encrypted to Bob Step2PublicKey. This binds AliceCertifiedKey and Step1PublicKey together. 4) Bob decrypts "actual message", verifies signatures with Step1PublicKey and AliceCertifiedKey, reads the message, sends back "his actual reply" and whatever signature certificate he wants to use (if any), signs with both Step2PublicKey and BobCertifiedKey. This binds BobCertifiedKey and Step2PublicKey together. At this point, there is no longer be a communication between two strangers, and the protocol is complete. The reason for the double-blind is to leak as little possible over the network to any of the interstital network service providers. If Alice wants to advertise her identity across the network such that Eve can read, she can provide Bob her actual identity certificate in step 1. If Bob doesn't want to wait for Alice to identify herself, he can provide his actual identity certificate in step 2. In general, this kind of negotiation has been avoided because email has always been viewed as an asynchronous protocol. However, there are factors perhaps in its favor: 1) People typically have at least one always-on connection nowadays. 2) People typically have more than one access device nowadays. 3) It is the only way that Alice and Bob can privately communicate their keys on the network without having access to a keyserver or LDAP directory and without scratch-making a new protocol unrelated to SMTP. 4) Keypairs are relatively cheap nowadays, so many more of them can be generated and used than our current protocols support. 5) Bob himself doesn't have to get involved until step 4. Bob's computer can do step 2 without bugging him. Alice has perhaps a bit more of a problem, she needs to hold her message in the queue until she's ready to do step 3. But again, this can be done automatically. 6) It significantly reduces the need for LDAP or other directory-querying code. 7) In a much more general sense, this is what people have to try to remember to do if they want to protect themselves on the network. What we need is a way to make it automatic. 8) The proposal presupposes that CAs exist in their current form, and removes several barriers to adoption of their services for email. Barring significant functionality gaps in current standards which make such a system and regime difficult to create, are there flaws in this logic that I'm overlooking? -Kyle H _______________________________________________ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
