We seem to be getting bogged down in arguments, so I thought I'd try and
get us closer to an actual document. If you like the following outline I
will pipe it into xml2rfc and flesh it out into something more detailed.
The approach I am taking is to perform the threat analysis in the context
of a rationale for DKIM, because this helps to explain what threats are in
scope and what are out of scope. It also helps to explain how DKIM fits
into the wider field of email security technologies, along the lines of
Eric's recent message.
identitifying an accountable entity
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
email has many identities, but they are all fairly weak
IP addresses currently strongest
problems with using IP addresses for accountability
volatile addresses, shared addresses
mismatch between message route and origin
why a domain-based identity would be an improvement
more information available as a basis for reputation
simpler black/white list management
some success already with domains from URLs used by spammers/phishers
using cryptography to provide stronger identification
problems with existing solutions
why we want to stuff the signature in the message header
and use the DNS for key distribution
<Pine(_dot_)LNX(_dot_)4(_dot_)60(_dot_)0508171837430(_dot_)8751(_at_)hermes-1(_dot_)csi(_dot_)cam(_dot_)ac(_dot_)uk>
vulnerabilities of email signatures
public archives expose sigs to offline attack
message modification in transit (mailing lists)
however this is usually done by the good guys not the bad guys!
network attacks
signature added to message after submission
low-level network attacks most likely during submission
out-of-scope - see RFC 2476, 2554, 3207
survey of email identities
how they might be strengthened
why they are difficult to use as they are
hostname (RFC 2821 EHLO)
routinely misconfigured or a total lie
out-of-scope - see e.g. CSA
return path (RFC 2821 MAIL FROM)
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 - see e.g. BATV
sender (RFC 2822 Sender:)
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)
authors (RFC 2822 From:)
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
resent-sender and resent-from
not widely used
822/2822 incompatibility
signer (new)
we can work with simpler semantics by introducing a new identity
(though DKIM provides some complexity here with d=/s=/i=)
can be tied to traditional identities with SSP
multiple signers may occur if message is re-sent
separately accountable, separate times and places
unlike authorship which is joint
Tony.
--
f.a.n.finch <dot(_at_)dotat(_dot_)at> 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