Hey elijah, this is cool. I really like the way you broke down categories and gave them names. Some thoughts:
As you note, *-endorsement really falls down to *-trust if the infrastructure is not set up to allow Bob to audit. But *-trust can be (manually) upgraded to *-endorsement if one keeps logs. If I record the TLS session between me and provider (and all the keys and such) I can show that as proof that either a) the provider had a rogue certificate issued for them or B) they lied. A service can still claim they/someone were hacked, whether it's a CA that led to a key lookup MITM or the infrastructure behind their endorsement key. If you're going to enumerate nuances of key authenticity, I think there's more. Some nuances that, to me, upgrade the authenticity of a key. - If I receive the key over an anonymous channel vs a bound channel. (e.g. Tor vs Internet) - If I receive the key over multiple Internet connections (Cellular & Broadband) - If I receive a signed response from the user, using that key - If I receive a signed response from the user, using that key, from a different provider (e.g. if I get an email from your riseup.net and leap.se accounts on the same key using UIDs) - In the grand unified communication context: if I receive the same key over another medium, e.g. OTR & Email - If I receive the same key from a user when they're on different devices. (Of course, this is actually near-impossible to prove, so it can't count for much.) So I envision keys gaining trust over time. Key Managers improve trust in keys by collecting endorsements, and tracking use. The more use in the more contexts, the more trusted a key is. An 'advanced' tab gives a number of details, like "This key is trusted because it's been endorsed by <N> independent endorsers, has been in use for <Y> months, and has been seen in <Z> independent contexts." Now let me click on a key, and send it to Carol. Bundle up the <N> endorsements, make a statement about <Y> and <Z>. Now I'm an endorser. And we have the Web of Trust back ;) -tom On 8 September 2014 01:50, elijah <[email protected]> wrote: > The threads here on key validation have been quite productive, but many > of the new email projects have need for some actual rules we can > implement in the here and now [1]. Most of these projects plan to > implement some form of TOFU, but there are many ways this could be done > and many ways this could transition to better key validation in the future. > > Here is a draft text for some basic rules to navigate this transition. > > https://pad.riseup.net/p/key-validation > > That link is live editable. Please comment, edit, deplore, or applaud as > you see fit. The full text is also included below for your convenience. > > -elijah > > [1] https://github.com/OpenTechFund/secure-email > > ---- begin ---- > > Transitional rules for automated key validation > > Intro > =================================== > > Although many interesting key validation infrastructure schemes have > been recently proposed, it is not at all clear what someone writing > secure email software today should do. In particular, most of the new > opportunistic encrypted email projects have proposed starting with some > sort of Trust On First Use, but there are many ways to implement TOFU > and many ways TOFU can interact with whatever more advanced schemes are > adopted in the future. > > This document attempts to specify generic rules for automatic key > management that can form a basis for proper TOFU and to transition from > TOFU to more advanced forms of key validation. In particular, the rules > try to define when a user agent should use one public key over another. > These rules are agnostic concerning what form these future systems of > key validation take. > > For systems that enforce a single channel for discovery and validation, > these rules are not useful. This document is only useful for the messy > situation we find ourselves in at the present time: there is a large gap > between what systems should do now in order to be immediately useful in > the current OpenPGP ecosystem and what should be done in the future. > > This document is written from the point of view of Alice, a user who > wants to send an encrypted email to Bob, although she does not yet have > his public key. > > We assume: > > * The goal is to automate the process of binding an email address to a > public key (we don't care about real identities). > * Alice knows Bob's email address, but not his public key. > * Alice might be initiating contact with Bob, or he might be initiating > contact with her. > * Bob might use an email provider that facilitates key discovery and/or > validation in some way, or he might not. > > Unless otherwise specified, "key" in this text always means "public key". > > Definitions > --------------------- > > * key manager: The key manager is a trusted user agent that is > responsible for storing a database of all the keys for the user, > updating these keys, and auditing the endorsements of the user's own > keys. Typically, the key manager will run on the user's device, but > might be running on any device the user chooses to trust. > > * key directory: An online service that stores public keys and allows > clients to search for keys by address or fingerprint. A key directory > does not make any assertions regarding the validity of an address + key > binding. Existing OpenPGP keyservers are a type of key directory in this > context, but several of the key validation proposals include new > protocols for key directories. > > * key discovery: The act of encountering a new key, either inline the > message, via URL, or via a key directory. > > * key validation level: the level of confidence the key manager has that > we have the right key for a particular address. For automatic key > management, we don't say that a key is ever "trusted" unless the user > has manually verified the fingerprint. > > * key registration: the key has been stored by the key manager, and > assigned a validation level. The user agent always uses registered keys. > This is analogous to adding a key to a user's keyring, although > implementations may differ. > > * key endorser: A key endorser is an organization that makes assertions > regarding the binding of username@domain address to public key, > typically by signing public keys. When supported, all such endorsement > signatures must apply only to the uid corresponding to the address being > endorsed. > > * binding information: evidence that the key manager uses to make an > educated guess regarding what key to associate with what email address. > This information could come from the headers in an email, a DNS lookup, > a key endorser, etc. > > * verified key transition: A process where a key owner generates a new > public/private key pair and signs the new key with a prior key. Someone > verifying this new key then must check to see if there is a signature on > the new key from a key previously validated for that particular email > address. In effect, "verified key transition" is a process where > verifiers treat all keys as name-constrained signing authorities, with > the ability to sign any new key matching the same email address. In the > case of a system that supports signing particular uids, like OpenPGP, > the signatures for key transition must apply only to the relevant uid. > > * endorsement key: The public/private key pair that a service provider > or third party endorser uses to sign user keys. > > Key manager rules > ==================================== > > (1) first contact: When a new key is first discovered for a particular > address, the key the highest validation level is registered. > > (2) regular refresh: All keys are regularly refreshed to check for > modified expirations, or new subkeys, or new keys signed by old keys > (precisely how updates work is out of scope of this document). > > (3) key replacement: A registered key MUST be replaced by a new key in > one of the following situations, and ONLY these situations: > > (a) verified key transitions (when the new key is signed by the > previously > registered key for same address). > > (b) If the user manually verifies the fingerprint of the new key. > > (c) If the registered key is expired or revoked and the new key is > of equal or higher validation level. > > (d) If the registered key has never been successfully used and the > new key has a higher validation level. > > Previously registered keys must be retained by the key manager, for the > purpose of signature authentication. These old keys are never used for > sending messages, however. Keys older than X may be forgotten. > > A public key for Bob is considered "successfully used" by Alice if and > only if Alice has both sent a message encrypted to the key and received > a message signed by that key. > > In practice, a key manager likely will implement rule 1 by trying every > possible validation and discovery method it supports, from highest level > to lowest, until it first gets a key and then it will stop. > > Validation levels > ==================================== > > Listed from lowest to highest validation level. > > 1. weak-chain > --------------------------- > > Bob's key is obtained by Alice from a non-auditable source via a weak > chain. By weak chain, we mean that the chain of custody for "binding > information" is broken. In other words, somewhere a long the way, the > binding information was transmitted over a connection that was not > authenticated. > > This form of key validation is very weak, and should either be forbidden > by the key manager or phased out as soon as practical. > > Examples: > > Alice initiates key discovery because she wants to send an email to Bob. > Alice queries the OpenPGP keyservers for an address that matches Bob's. > This is a weak chain because anyone can upload anything to keyservers. > > Bob initiates key discovery by sending Alice an email that is signed, > but Bob's email provider does not support DKIM. Alice takes the > fingerprint from the signature and queries the OpenPGP keyservers to > discover the key. This is a weak chain because there is nothing to stop > anyone from sending an email that impersonates Bob with a fake "From" > header and fake signature. > > 2. provider-trust > ---------------------------- > > Alice obtains binding information for Bob's key from Bob's service > provider, via a non-auditable source over a strong chain. By strong > chain, we mean that every connection in the chain of custody for > "binding information" from Bob's provider to Alice is authenticated. > > To subvert "provider-trust" validation, an attacker must compromise > Bob's service provider or a certificate authority (or parent zones when > using DNSSEC), but it also places a high degree of trust on service > providers and CAs. > > Examples: > > Bob initiates key discovery by sending Alice an email that is signed by > Bob, and there is a valid DKIM signature from the provider for the > "From" header. Alice takes the fingerprint from the signature and > queries the OpenPGP keyservers to discover the key. This is > "provider-trust" because the DKIM signature binds the sender address to > the fingerprint of Bob's key, and presumably Bob authenticated with his > service provider. This also assumes Alice's user agent is able to > securely discover the DKIM public key for Bob's provider. > > Alice initiates key discovery for Bob's address, checking webfinger or > DNS. These queries by Alice are 'provider-trust' so long as the > webfinger request was over HTTPS (and the server presented a certificate > authenticated by a CA known to Alice) or the DNS request used > DANE/DNSSEC. This relies on a reasonable assumption that if a provider > publishes keys via DNSSEC or HTTPS then the provider probably also > required some authentication from the user when the user uploaded their > public key. > > Bob initiates key discovery by sending Alice an email that contains an > OpenPGP header that specifies a URL where Alice may obtain Bob's public > key. Bob's email contains no DKIM signature, so it could have been sent > by anyone. However, the URL is in a standard form such as > https://example.org/.well-known/webfinger?resource=acct:[email protected]. > If the "From" header matches the domain, the URL is in a standard form, > the email address in the URL, and the HTTPS connection is authenticated, > then Alice may consider this "provider-trust." This is because, > regardless of who actually sent the email, what Alice sees as the sender > matches what the provider is queried for. All these conditions are > unlikely to be met in practice, but the example serves to illustrate the > broader point. > > 3. provider-endorsement > ---------------------------------------- > > Alice is able to ask Bob's service provider for the key bound to Bob's > email address and Bob is able to audit these endorsements. Rather than > simple transport level authenticity, these endorsements are time stamped > signatures of Bob's key for a particular email address. These signatures > are made using the provider's 'endorsement key'. Alice must obtained and > register the provider's endorsement key with validation level at > 'provider-trust' or higher. > > An auditable endorsing provider must follow certain rules: > > * The keys a service provider endorses must be regularly audited by its > users. Alice has no idea if Bob's key manager has actually audited Bob's > provider, but Alice can know if the provider is written in such a way > that the same client libraries that allow for submitting keys for > endorsement also support auditing of these endorsements. If a key > endorsement system is not written in this way, then Alice's key manager > must consider it to be the same as "provider-trust" validation. > > * Neither Alice nor Bob should contact Bob's service provider directly. > Provider endorsements should be queried through an anonymizing transport > like Tor, or via proxies. Without this, it is easy for provider to > prevent Bob from auditing its endorsements, and the validation level is > the same as "provider-trust". > > With provider-endorsement, a service provider may summarily publish > bogus keys for a user. Even if a user's key manager detects this, the > damage may already be done. However, "provider-endorsement" is a higher > level of validation than "provider-trust" because there is a good chance > that the provider would get caught if they issue bogus keys, raising the > cost for doing so. > > 4. third-party-endorsement > --------------------------------------- > > Alice asks a third party key endorsing service for binding information, > using either an email address of key fingerprint as the search term. > This could involve asking a key endorser directly, via a proxy, or > asking a key directory that includes endorsement information from a key > endorser. > > A key endorser must follow certain rules: > > * The key endorser must be regularly audited by the key manager. Alice > has no idea if Bob's key manager has actually audited a particular key > endorser, but Alice can know if the key endorser is written in such a > way that the same client libraries that allow for submitting keys for > endorsement also support auditing of these endorsements. If a key > endorsement system is not written in this way, then Alice's key manager > must consider it to be the same as "provider-trust" validation. > > * The key endorser must either require verified key transitions or > require that old keys expire before a new key is endorsed for an > existing email address. This is to give a key manager time to prevent > the user's service provider from obtaining endorsements for bogus keys. > If a key endorsement system is not written in this way, Alice's key > manager must consider it to have the same level of validation as > "provider-endorsement". > > 5. third-party-consensus > ----------------------------------- > > This is the same as third-party endorsement, but Alice's user agent has > queried a quorum of third party endorsers and all their endorsements for > a particular user address agree. A variant of this could be "n-of-m" > validation, where Alice's user agent requires 'n' endorsements from a > set of 'm' endorsers. > > 6. historical-auditing > ----------------------------------- > > This works similar to third-party-endorsement, but with better ability > to audit key endorsements. With historical auditing, a key endorser must > publish an append-only log of all their endorsements. Independent > "auditor" agents can watch these logs to ensure new entries are always > appended to old entries. > > The benefit of this approach is that an endorser is not able to > temporarily endorse and publish a bogus key and then remove this key > before Alice's key manager is able to check what key has been endorsed. > The endorser could try to publish an entire bogus log in order to > endorse a bogus key, but this is very likely to be eventually detected. > > As with other endorsement models, the endorsement key must be > bootstrapped somehow using a validation level of "provider-trust" or > higher. > > 7. known-key > ----------------------------------- > > Bob's key has been hard-coded as known by the software (mostly this just > applies to keys belonging to established endorsers, not user keys). > > 8. fingerprint > ---------------------------------- > > Alice has manually confirmed the validity of the key by inspecting the > full fingerprint or by using a short authentication string with a > limited time frame. For extra whimsy, fingerprint inspection should take > the form of a poem. > > Future specification > =================================== > > These are out of scope for the specific problem of key validation, but > these are important issues that need to be addressed when transitioning > to opportunistic encrypted email over time. > > Issuing new keys > -------------------------- > > As these rules are written, if Alice loses her private key but still has > access to her email account, she will not be able to send signed mail or > receive encrypted mail until the expiration date on the key (assuming > all the clients respect the key expiration date). > > For example, imagine Alice loses access to her private key but the key > will not expire for another month. She can still authenticate with her > service provider, so she can still issue new keys and have the service > provider endorse them, or some other party endorse them. But, no valid > client should use them yet until her lost key expires. > > Effectively, the primary key's expiratation date is the window of time > that Alice is willing to put up with being locked out of using encrypted > email. This window is also the same length of time that Alice has of > detecting, by audit, a provider that is publishing bogus keys for her > (before those keys potentially start to get used). So, if Alice wants > high convenience, she can set this window to be short. If Alice wants > higher security, she can set this window to be long. > > At this point, it is unclear what a good value for key expiration > should be for users who want higher convenience and for users who want > higher security. > > If a key expiration date is too soon, then there is a possibility that > Alice's key manager will not have had the opportunity to extend the key > expiration (for example, perhaps Alice is traveling and does not check > email for several weeks). Alice can still recover, since a key can still > have its expiration date extended after the key has expired, but this is > still not ideal. Alice should be able to indicate that she is > confortable with the provider always being able to issue new keys on her > behalf. It would be impractical to set the key expiration to always be > one day in the future. As a refinement, a future protocol should support > a special date annonation on a public key that says "brand new keys may > be accepted for this address after this date". If this annotation is > present, the expiration date is then only used to determine the point in > time after which a key should not be used, not the cutoff for accepting > replacement keys. > > Updating keys > -------------------------- > > For high usability, a key manager will need to frequently update keys by > querying a key directory or the original source of the key. Every key > validation proposal has a different mechanism for this. The important > thing is that Alice's key manager should not make queries in a manner > that leaks Alice's addressbook to the key directories. As one example, > the program parcimonie will slowly update keys, one at a time, from > traditional OpenPGP keyservers over Tor. Also, because these updates > need to happen frequently, the key manager should have some way to first > test to see if a key is modified before downloading the full key (using > something like an etag). > > Sending email > -------------------------- > > To avoid encrypted email being sent to people who no longer use OpenPGP, > the user agent should not opportunistically encrypt outgoing mail to a > recipient unless the recipient has positively indicated they wish to > receive encrypted email. Such indication may include: a signed email > message, a public key as an attachment, an OpenPGP header, a key > published by the provider or key directory (but NOT a HKP keyserver), or > when the user performs manual fingerprint verification. > > When Alice sends an email with an opportunistic mail user agent, the > agent should always try to indicate that Alice prefers encrypted email. > This could be done by signing every message, although that can raise > security issues as well. > > Receiving email > -------------------------- > > As alluded to above, an opportunistic mail user agent that receives a > message from a provider that does not support DKIM signatures on the > From header should be cautious when using the OpenPGP signature or > OpenPGP header to discover and register the sender's public key. These > emails are easily spoofed by anyone on the internet, causing the user > agent to register impostor keys. > > Device keys and subkeys > -------------------------- > > It would be highly desirable for all projects that use OpenPGP to > support device keys. The idea is that a user might have multiple > devices, with different keys for each device (instead of needing to > synchronize the same private key to all their devices). How might this work? > > If Bob's master key has multiple subkeys with (E)ncryption usage for the > uid in question, then Alice should encrypt the message to ALL those > subkeys when sending email to Bob. > > A system using subkeys like this still requires a single master key. It > may be desirable for a key validation protocol to allow for a single > email address to be bound to multiple master public keys, although this > is not supported with the current rules in this document. > > Phasing out > -------------------------- > > Ideally, there should be some mechanism to phase out lower forms of > validation as higher forms become more common. In particular, it would > be good to forbid weak-chain validation entirely. > > > > > _______________________________________________ > Messaging mailing list > [email protected] > https://moderncrypto.org/mailman/listinfo/messaging _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
