On Mon, 15 Aug 2005, Michael Thomas wrote: > I think that there's one other important aspect that's hard > for me state concisely. Utility is often bound up in the network > effect, and though PGP and SMIME solve for many of the threats > -- equally or superior -- they have not achieved any sort of > network effect. I believe that DKIM by design is specifically > trying to address the network effect and make it a goal. We > have made some specific design decisions that are ultimately > traced back to that goal: > > 1) use of DNS, and our lowering the bar on cryptographic trust anchors > 2) lowering the expectation of what is actually asserted (ie, domain > based rather than individual based) > 3) absolutely no attempt to deal with encryption > 4) the ability to ride "stealthfully" within the existing > infrastructure without need to upgrade either MTA's or MUA's > 5) ease of deployment at choke points (MTA's), and into existing > naming infrastructure (DNS) > > I'm not sure that I ultimately know where the network effect will > take us -- can anybody really predict such a thing with better than > random odds? But pervasive authentication even with lowered expectations > seems like it will enable a lot of things that point solutions with > higher barriers will cannot.
I'll turn Michael's message above into a slightly more formal arrangement which might be useful in a threat analysis document. THREAT: clumsy key management draft-iab-messaging-report-00 says in section 3.6 "Identity Hints and Key Distribution": While it is widely recognized that both message encryption and authentication of conversation partners are highly desirable, the consensus of the workshop participants was that current business and implementation models in part discourage deployment of existing solutions. For example, it is often hard to get new root certificates installed in clients, certificates are (or are perceived to be) difficult or expensive to obtain, one-click or zero-click service enrollment is a worthy but seemingly unreachable goal, and once one has created a public/private key pair and certified the public key it is less than obvious how to distribute that certificate or discover other people's certificates. EFFECTS: The clumsy key management of existing email security protocols has contributed to their poor deployment. SOLUTION: draft-iab-messaging-report-00 suggestst that this threat can be addressed by using the DNS to provide simpler trust anchors and simpler mechanisms for key distribution and revocation. CONSEQUENCES: This solution depends on the security of the DNS, so in the absence of DNSSEC it does not provide a cryptographically secure identification of the signer to the degree that existing protocols do. However this weaker identity is still much stronger than most email identities currently available, and it is probably strong enough to support new security features within the message transport system (as opposed to archival quality security). THREAT: obtrusive signatures Existing email security protocols place the signature in the body of the message. When these messages are handled by legacy clients that do not understand the security protocol, the recipient is presented with ugly visual clutter or even a completely unreadable message. EFFECTS: Again, this has contributed to the poor deployment of email security protocols. SOLUTION: Unknown header fields are usually hidden by existing MUAs. By placing the signature in the header we can add security information to a message in a way that is unobtrusively backwards-compatible with clients that do not support the new security protocol. CONSEQUENCES: Keeping security information in the message header in a way that is compatible with legacy clients means that we cannot support message encryption, which necessarily requires support from the recipient's MUA and requires that cryptographic data appears in the message body. This is probably a useful simplification rather than a disadvantage, and in any case encryption is still supported by existing email security protocols. THREAT: poor scaling factors Existing email security protocols are designed to work between inividual users. This implies per-user scaling factors, such as the number of keys that must be managed, and the number of software installations which must support the protocol. EFFECTS: Again, this has contributed to the poor deployment of email security protocols. SOLUTION: A security protocol which is designed to operate between domains has better scaling factors. As well as the numbers being much smaller, email system administrators are much more expert than the general user population, and so they are better able to perform the necessary upgrades and configuration. CONSEQUENCES: Simple per-domain signing is probably not sufficient to deal with some of the more complex email usage scenarios, such as outsourced mailing list management. Therefore a new protocol should have some support for domains to delegate signing privileges independently of email domains used to identify the message's author or sender. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ BISCAY: WEST 5 OR 6 BECOMING VARIABLE 3 OR 4. SHOWERS AT FIRST. MODERATE OR GOOD. _______________________________________________ ietf-dkim mailing list http://dkim.org
