Colleagues - I agree. Some minor observations ...
1. How about spelling "principal" correctly?
2. At the end of the final paragraph, how about inserting ... "However, an associated reputation system can properly distinguish between these addresses."
3. Suggestion for alternative wording of point 3, paragraph 2: "This, in turn, allows content analysis engines to characterize originating domains for the purpose of efficient processing of received messages." It's slightly more general and highlights the benefit of improved efficiency, i.e. lower cost.
All the best. Tim.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Arvel Hathcock
Sent: Tuesday, August 30, 2005 9:37 PM
To: [email protected]
Subject: Re: [ietf-dkim] Revised threat model
You know, I think the text below is rather good.
--
Arvel
----- Original Message -----
From: "Hallam-Baker, Phillip" <[EMAIL PROTECTED]>
To: "IETF-DKIM" <[email protected]>
Sent: Tuesday, August 30, 2005 9:29 AM
Subject: [ietf-dkim] Revised threat model
> If the proposed revisions are made to the charter then the threat
> model is considerably easier to articulate. Note that we are not
> promising *less*, we are simply stating the claims more precisely.
>
>
>
> 1. Who are the bad actors? (Characterize them, eg, what resources do
> they have?)
>
> The bad actors are a variety of Internet criminals who exploit the
> lack of authentication in SMTP email to create messages that purport
> to come from another party.
>
> The principle concern is caused by professional Internet criminals
> with access to significant computation and network bandwidth
> resources. These resources are typically stolen, the criminals either
> establishing their own 'botnet' or renting the use of an existing
> botnet from another party.
>
>
> 2. Where do they fit into the protocol environment (eg, middle of
> net)?
>
> The Internet criminals of concern typically operate at the edge of the
> net. In some cases the criminals have access to backbone routers and
> have the ability to inject fake BGP routing information.
>
> The cryptographic approach described does not depend on the location
> of the attack being limited to a particular part of the protocol
> environment except to the extent that the approach depends on the
> security of the DNS and does not propose replication of existing work
> on DNSSEC.
>
>
> 3. What are we trying to prevent them from doing?
>
> The objective of DKIM is to prevent an Internet criminal stealling the
> reputation associated with an existing DNS domain name by creating
> spoof emails that impersonate a domain.
>
> The message signature format and the security policy mechanisms allow
> a sender to specify which emails they accept and deny responsibility
> for. This in turn allows spam filtering engines to compile and apply
> reputation information more accurately.
>
>
> As currently defined DKIM is only designed to provide a machine
> readable authentication mechanism. Although DKIM information MAY be
> presented to a human reader the authentication mechanism currently
> defined is NOT designed to prevent impersonation of other identifiers
> that a human reader might rely on. In particular DKIM does not provide
> protection against the use of 'cousin' or 'lookalike' addresses in a
> phishing attack.
>
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
>
>
_______________________________________________
ietf-dkim mailing list
http://dkim.org
_______________________________________________ ietf-dkim mailing list http://dkim.org
