]> University of Cambridge Computing Service

New Museums Site Pembroke Street Cambridge CB2 3QH ENGLAND +44 797 040 1426 dot@dotat.at http://dotat.at/

Security DKIM XXX $Cambridge: hermes/doc/antiforgery/draft-fanf-dkim-rationale.xml,v 1.3 2006/02/28 18:47:54 fanf2 Exp $

XXX

an accountable entity is someone who is willing to accept the consequences of emitting email that the recipients don't like e.g. blacklisting, filtering performance improvements from avoiding filtering of known-good email email has many identities, but they are all fairly weak; the IP addresses currently strongest

volatile addresses, shared addresses mismatch between message route and origin

more information available as a basis for reputation simpler black/white list management some success already with domains from URLs used by spammers/phishers

Replay attacks - direct and parasitic. Fine-grained keying. Revocation IDs. Revoking delegated key selectors.

Use of signatures as a tool to provide a strong identity; other applications of crypto sigs are irrelevant or incidental (non-repudiation, message integrity, etc.) problems with existing solutions why we want to stuff the signature in the message header and use the DNS for key distribution see <Pine.LNX.4.60.0508171837430.8751@hermes-1.csi.cam.ac.uk>

public archives expose sigs to offline attack; message modification in transit - however usually done by good guys not bad guys! (mailing lists) how to make signature robust against reasonable modifications and resistant to attack? contradictory requirements

signature added to message after submission; low-level network attacks most likely during submission out-of-scope for DKIM - see .

how they might be strengthened and/or why they are difficult to use as they are Identity names are clarified by reference to the relevant commands described in or header fields described in .

routinely misconfigured or a total lie out-of-scope for DKIM - see e.g. . However hostname verification can be used to optimise certain DKIM checks.

original message data often not present in bounce messages so a signature in the message can't be used to secure this -> security tag in the address itself out-of-scope for DKIM - see e.g. .

often not displayed to recipients so strengthening it may not be all that useful problems with the way it is currently used e.g. mailing lists problems related to authors also apply to sender (except for multiple authorship)

roaming users should still be supported e.g. where the accountable identity is the ISP that runs the smart host not domain of author(s) multiple authorship is awkward to handle especially because of the preceding

not widely used; invisible if re-sending is actually forwarding; / incompatibility

we can work with simpler semantics by introducing a new identity (though DKIM provides some complexity here with d=/s=/i=) may multiple signers occur if message is re-sent? separately accountable, separate times and places unlike authorship which is joint

tied to traditional identities with SSP

This entire document discusses security weaknesses in Internet email and how they might be mitigated.

&rfc2821; &rfc2822; Sendmail, Inc. PGP Corporation Yahoo! Inc. Yahoo! Inc. Cisco Systems, Inc. Cisco Systems, Inc. &rfc0822; &rfc2476; &rfc2554; &rfc3207; Taughannock Networks Brandenburg InternetWorking Openwave University of Cambridge Mail Abuse Prevention System Brandenburg InternetWorking JLC.net

This document specifies no actions for IANA

Ned Freed pointed out the distinction between the use of cryptographic signatures as a tool and as a higher-level service. <01LS5XOD9DPU000092@mauve.mrochek.com> Doug Otis suggested the use of HELO verification to optimise certain DKIM checks, and the use of revocation IDs to deal with replay attacks. <7B3DE745-64F5-4593-8DC4-2597C1D1B1CA@mail-abuse.org> Michael Thomas provided a list of deployment problems with existing cryptographic email security protocols and how these are addressed by DKIM. <4300FC01.80406@mtcc.com>