On Wed, 2007-07-11 at 09:55 +0200, Eliot Lear wrote: > Doug, > > > > > When short cuts are taken in PKI as with SMTP, there should be some > > concern. > > > > DKIM voids vetted CAs, as the public key is obtained from DNS, this > > provides the URL association directly. > > It's really not the same. The implications of a compromised DKIM key > are bilateral *at best*, whereas a CA, particularly a well known one > will have far broader impact. > > But that's not what I was talking about. What I was referring to was > Ohta-san's implication that PKI is fundamentally flawed. Perhaps it is, > but I don't see anything better for key distribution to millions of > people. If you, he, or anyone else comes up with something better, I'm > all ears. I agree with your statements about PKI. PKI helps formalizes safe procedures to exchanging information. PKI also reduces the number of entities who's attention to these procedures needs to be vetted. For DKIM, an ad-hoc exchange of keys or the delegation of a zone are the methods available to authorize a third-party. This authorization could often be needed to permit a provider's added signature be recognized as authoritative. This is accomplished by making the signature by the third-party transparently appear to be that of their customer. How keys are exchanged or handled might be accomplished in any number of ways. A provider may find it easier to collect private keys and selector locations, issue public keys and selector locations, or obtain a zone of their customers to permit them to directly deal with keys and selectors to better manage key rollovers. When a service provider becomes compromised in some manner, the many domains they provide signatures for could be at risk. The private key or keys the provider uses could be used to spoof the messages for any of their customers from any SMTP client. These keys are likely distributed to many servers connected to the Internet. This might also include keys published in DNS when the service provider controls different zones for thousands of other domains. The use of these keys may not be limited to just DKIM as well. Without an authorization by-name mechanism for DKIM, the recipient is unable to vet which third-party they are trusting. The originator would also need to hope their keys are handled safely using some ad-hoc procedure. When one of these third-parties becomes compromised, users would need to be asked to check which key selectors were used to sign messages for perhaps thousands of different domains. This could be a rather daunting list caused by just one compromise. DKIM could prevent this type of unmanageable compromise situation by using an by-name authorization scheme instead. DKIM should recommend against an exchange of keys or the delegation of zones. When keys used by provider-x becomes compromised, all their customers will be able to retract their authorization record, and just signatures made by provider-x would then be suspect. When dealing with a compromise situation, a simple report is all that is needed. As it is now, a compromise report may look like an encyclopedia of keys and selectors. The impact would be much more painful to those compromised as well. The report would need to list all their customers. Those customers will likely receive phone calls from competitors. Knowing this, the temptation would be to not report a breach, and require each of their customers to report a problem as it gets discovered by them perhaps much later. One compromise may then sound like an epidemic of compromises. Authorization by-name and not by key exchange is a much safer alternative DKIM. Authorization by-name would also permit the detect of possible replay abuse made impractical with ad-hoc key exchanges. -Doug _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf