On Jun 11, 2009, at 7:05 AM, Dave CROCKER wrote: > If out-of-band algorithm/key-type registration like this is not a > regular "protection" mechanism provided in existing, related crypto- > based schemes: > > 1) Why should it be only in DKIM?
DKIM offers a domain's credentials to messages experiencing massive spoofing. For DKIM, senders and receivers can indicate which algorithms are supported via DNS records. After all, DKIM headers can not be trusted until the signature is verified. When verification is not possible due to an unsupported algorithm, this algorithm may be refuted by the signing domain using their DNS record. The ability to refute an algorithm defends against the types of exploits that Stephen mentioned, AND against a massive confusion for the disposition of messages when recipients are unable to determine which domains adopted a new algorithm. DKIM signature analysis offers three conclusions that are supported and in current use: a) Refuted b) Invalid c) Valid The refuted state improves algorithm agility in the face of the massive spoofing. > 2) Won't it need expert vetting by the security community to > validate that the threat is real and the protection is sufficient? It seems that has happened two years ago. The changes now being suggested remove some of the protections in current use. > I have been repeatedly taught by the security community to be > extremely cautious about casual assumptions of what will fix a > theoretical exposure. So, for example, there have been cases where > encrypting twice using the same algorithm reduces protection rather > than raising it. That ain't intuitive. > > Same concern here. > > Having this information maintained in the DNS isn't free and isn't > certain to be safe. Indeed, some recent extensions to email threaten DNS security. Information published by a domain via DNS is often less expensive than when using HTTP or SMTP due to extensive caching of DNS. Regardless of cost, or email's impact on DNS security, email still relies heavily upon DNS whenever deciding which servers receive messages, and in the case of DKIM, how to verify a domain's possession of a private key. Even PKI management is likely to have relied upon DNS at some point. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
