Tony,
While I like your outline quite a bit, my inclination is to stick closer
to the specific questions that Russ posed (Who are the bad guys and what
are they capable of? Where are they in the system? What do they want to
do?). The more that we expand beyond that the more likely we are going
to get tied up in a debate, perhaps about something that we don't need
to resolve right now.
My suggested format would be major sections around the questions, and
minor sections around the answers as I suggested the other day in
http://www.mipassoc.org/pipermail/ietf-dkim/2005q3/000371.html
So my suggested outline would be something like:
The Bad Actors
Those asserting arbitrary identities
Those asserting specific identities
Identity related fraud
Exploitation of social relationships
Capabilities of Bad Actors
Actors with little financial motivation
Message generation using unauthorized domains
Message generation using domains under attacker control
Modification of legitimate messages
Masquerading as a mailing list
Actors with significant financial motivation
DNS attacks, e.g., cache poisoning
Key storage corruption and/or key misappropriation
Man-in-the-middle attacks
Obtaining signature illegitimately
Circumventing/corrupting the verification process
Where are the bad actors?
Originating domain
Recipient domain(s)
Intermediaries, e.g., mailing lists
Elsewhere (interdomain space)
Bad acts
Obfuscation of message origin
Exploitation of social relationships
Fraud associated with use of trusted address
-Jim
Tony Finch wrote:
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.
_______________________________________________
ietf-dkim mailing list
http://dkim.org