On Jan 26, 2006, at 4:45 PM, Jim Fenton wrote:
Here's my rationale for the values I put in the document regarding
Signed Message Replay.
There should perhaps be a third column in addition to "impact" and
"likelihood"; let's call it "utility". The Signed Message Replay
attack in section 4.1.5 differs from nearly all of the other
attacks in that the attacker can't do everything they'd perhaps
like. If they steal the private key for the domain, they can sign
any message they like and send out advertising or objectionable
material, etc. With the SMR attack they can't do that -- they can
only inappropriately distribute things that are already signed.
This can be bad for the domain's reputation, but if the attacker is
looking to sell pharmecuticals, this isn't going to help.
So I marked this attack as "low impact", in part because of its
limited utility, and in part because (in accordance with the
definitions in section 1.2) this attack deals with individual
messages -- it doesn't affect the majority of the messages from the
domain, only those selected by the attacker for replay. Perhaps
the definitions need adjusting but I think we need some objective
means for scoring the threats.
I do recognize my role on this is as a document editor, and I will
adjust the document to group consensus, but I wanted you to know
where I was coming from.
The Low/High impact of replay abuse depends upon the expected role of
a DKIM signature, and how a "good" actor can be differentiated from
that of a "bad." Challenging this "Low" impact rating is questioning
whether acceptance of the _message_ or the _signing-domain_ will be
modified as a defensive measure. To suggest the impact from replay-
abuse would be "Low" also suggests an expectation of isolating
assessments on either a matching email-address or perhaps the
signature, but not on the signing-domain. It seems that one should
consider what this approach entails when resolving accountability
beyond that of the signing-domain.
With tens of millions of domains, each domain may also support
hundreds of millions of email-addresses. There is virtually no cost
associated with an email-address, nor is there a limit to the number
of email-address that might be created. Using the signature itself
would further increase the assessment database by orders of
magnitude. If the recipient finds that resolving beyond the domain
to be problematic, there would be two choices:
1) hold the signing-domain accountable for the abuse
2) ignoring the signature altogether
When a newsletter or promotional ad is distributed well beyond a list
of subscribers, is this a case of:
1) an unintended replay by a miscreant
2) the marketing department relying upon an inability of an
assessment to differentiate good from bad
When dealing with large organizations, these assessments must be
defendable. Many companies already use third-parties to distribute
these types of messages. When enough of this abuse becomes common
place, any such abuse may result in the signing-domain being blocked,
perhaps out of frustration.
Many domains leak rate restricted abuse from perhaps tens of
thousands of compromised systems offered access. Monitoring or
outbound filters will not be effective control measures. There are
any number of messages between friends and colleagues that take the
form:
Give me your opinion on this.
http://tinyurl.com/1234
Is it practical for a recipient to assess accountability for
individual messages? Should the recipient filter on signatures?
Should the recipient attempt to hold each email-address separately
accountable? The unlimited supply of email-addresses would seem to
suggest that this strategy may be futile.
It seems from the Low impact assessment, you expect the recipient to
make significant accommodations and to pick and choose messages from
within a signing-domain. It would also seem that by even attempting
to make this type of accommodation, a signing-domain would need to
constrain the use of email-addresses. Domains that offer email-
addresses like list-master will be in greater peril unless each
posting changes this email-address.
-Doug
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org