ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] proposed threat analysis outline

2005-08-22 21:32:18
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