Subject: TECH-OMISSION: Security vulnerability - Malicious DSN attacks

From: "Chris Haynes" <[email-masked]>
Date: Mon, 30 Aug 2004 08:23:03 +0100

In draft-ietf-core-03.txt section 6 (Security Considerations) add a new
section...

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

6.5  Malicious DSN attacks on third-parties

There is class of attacks in which an attacker A can entice a participant P to
send a malicious message to a victim V.

These attacks are undertaken by A citing the address of V in the SMTP Mail-From
request and then by causing P to generate (or invoke the generation of) a
Delivery Status Notification 'bounce' message (RFC3464), which is sent to the
victim V.

The attacker relies upon it being common practice to copy the original message
into the 'bounce' report, thereby causing the malice to be sent onwards to V.

This mode of attack has the advantages (to the attacker)

-  of obfuscating the location of the host from which the attack was mounted

-  of possibly damaging the reputation of P by making it appear
     that P originated, or was an active participant in, the sending
     of the malicious message.

In current practice, A causes P to invoke the 'bounce' by addressing the
original message to a non-existent recipient.

Sender-ID enables a new variant of this attack.

In this variant the attacker A sends a message whose PRA (section 4) is selected
by the attacker to be such that, when P undertakes the Sender-ID test, a 'Fail'
will result (section 5.3).

The message will be rejected (as the attacker intended) and a malicious 'bounce'
message may be generated and sent to the victim V.

^^^^^^^^^^^^^^^^^^^^^^^^

... and add a new Normative reference to RFC3464 in section 10.1

============================

Rationale for new section

This new mode of attack has been discussed extensively in the thread
"DEPLOY: Legal liability for creating bounces from forged messages", and has
been mentioned in others.

It has been accepted by proponents of Sender-ID that this mode of attack can
occur; the debate has been about whether or not Sender-ID or should provide any
defence against this attack.

The extant draft contains no such defence, hence the need to declare this
security vulnerability within the draft.

Chris Haynes