ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Re: An overview of cryptographic protocols to preventspam

2005-09-26 12:42:47
Douglas, many thanks for your many comments and suggestions; see some responses inline.

Best, Amir

p.s. I'm copying DKIM since obviously Douglas thought (contrary to me) that this is relevant. However, I still think this discussion belongs in general security/spam forums e.g. asrg (so I copy asrg). I think in this whole note there is only one small point specific to DKIM. So Douglas or others, if you care to respond, please consider using ASRG or another appropriate forum... I'm also adding SES list since it Douglas referred to it (at the end).

Douglas Otis wrote:

On Sep 25, 2005, at 11:40 PM, Amir Herzberg wrote:
I agree that labeling seems difficult to deploy. However, I think that when there is a widely accepted label, e.g. ADV in subject line, then sending appropriate content (advertisements) with this label is an acceptable practice. Therefore, I do not regard this as spam. Such well-labeled email can be easily filtered, of course, and most recipients (and maybe mail servers) may do so. Do you object and if so, why?


Offering a label that a message is an advertisement does _not_ indicate whether the message was solicited.
Indeed, I think we agree on the (trivial) observation, that by looking only at the message we can't know if it was solicited.

Any advertisement, labeled or not, representing one of perhaps an inordinate number of such messages should _still_ be viewed as spam. Such messages are primarily in the sender's interest, and primarily at the expense of the recipient.
If properly labeled (e.g. with ADV:) then filtering them becomes trivial. And if you are willing to accept ADV: (or other label) from specific senders, use appropriate authentication mechanisms (e.g. DKIM) to allow these senders (only) and block ADV: from others.

The test for whether a message is spam should not be solely based upon some header being falsified.
Why not? A simple definition that can be validated is very useful.

If 'ADV:' on the subject line were to mean "this is not spam," then of course every spammer would use this label.
Not when ADV: also means `this is an ad` and 99.9% of users block it (at least from all but very few selected senders)... And this is, in reality, already the case. Spammers rarely put ADV:... even when required by law. Hence the need for `Internet enforcement`.

If it were used conscientiously to genuinely indicate an advertisement to an individual requesting such information, then of course such a message should not be filtered. As there must be a mechanism based upon reputation to determine the integrity of the sender anyway, such labeling would be of extremely little value.
Here I disagree. Current mechanisms use _implicit_ labels of `no ads, no virus, ...` - and if you'll read my text, I indeed said that `no label` equals a default of `not falling into one of the required labels`. The labeling mechanism allows senders to send an ad to customers who want it, and allow me to send a virus to an anti-virus researcher. I think this is important for free speech and some legitimate usage scenarios.

Assume responsible senders would cease sending advertisement when requested, and that such responsible senders also predicate sending based upon a request or granted permissions.
Yes? And how would a recipient know that a sender is `responsible`? Based on unproven assertions by blacklists etc? Having signed labels allows one to _prove_ that somebody cheated.

In any case, may I suggest you respond to me privately or in an appropriate forum e.g. asrg, since I think content labels are not part of DKIM (of course DKIM can be applied to sign such labels).

DKIM itself could be viewed as a type of label that can be verified.
DKIM signatures do not contain description of the content (i.e. content label). I was not discussing any `label` just `content labels` .

The domain of a compromised router does not need to be within the recipient's domain, as you indicate.
Didn't understand.

There is a difference between a black-list and a black-hole list, where black-hole list would be the preferred terminology describing an IP address qualification mechanism.
Why do you think this is a better term? How do you define the difference?

The path based registration schemes are very prone to intra-server attacks, in addition to man-in-the-middle attacks.
What is an intra-server attack? You mean attack on DNS server??

Many MTA are shared by multiple domains. There should be some mention that mailbox-domain authorization schemes attempt to base authorization upon visible headers, where this then violates normal conventions. This is also true for SSP. The solution often used for cases where authorization would inadvertently cause a message to be lost, is to use open-ended authorization. Open-ended authorization may invite exploitations and may cause messages to placed into "junk" folders, rather than rejected with an indication of a delivery failure.
Sorry - didn't understand this paragraph. Please clarify.

Your "ALL" chart lists '+', where this could be seen as the "politically incorrect" mode.
What do you mean by PC here?
The normal approach would be to use the open-ended '?' mode. Characterization of path based registration as being simple to implement or alluding to lower CPU overhead is misleading. These path based schemes may require an inordinate level of DNS lookups consuming limited I/O resources, whereas CPU resources used for cryptography are generally available and otherwise unused.
I meant path based is less `expensive` than content-based; and on the CPU vs. I/O, I think the story is not clear, esp. since most crypto proposals also involve DNS queries. I'll try to clarify.
You also question the value of utilizing reputation based upon the domain. The domain does carry more information than just the IP address. IPv6 addressing may create a similar situation. A name offers the age and the registrar of the domain.
But my concern is that registring names is cheap (and of course could be done in advance). Any solution to this concern?

When considering the number of shared MTAs, the use of path registration remains dubious, whereas being able to verify the name offers greater value. Even with DKIM, the mailbox-domain may not be assured and not be verifiable This is also true for the path registration techniques. Authorizing a mail service _does not_ indicate that mailbox-domain originated the message. There is far greater risks associated with "poisoning" reputations based upon mailbox-domain authorizations, which are mechanisms being currently proposed. Basing reputation upon DKIM signatures should eliminate most poisoning concerns. This would assume that a replay mechanism is in place.
I think we agree here so I'm not sure if this is a comment/criticism/suggestion on my write-up, if it is, where do you think I should clear it up?

Although some see BATV and SES as similar solutions, I would rather see BATV used as an example for signing the bounce-address. See Dave Crocker's explanation regarding the differences between these approaches.
Well, I need to read SES again to confirm, but I believe my impression was that - contrary to Dave's note - SES also allowed the sending domain to be stateless. I did have reservation on the fact it seemed to require recipient domain to be stateful if using `two side SES` (which I think BATV does not offer at all?); I wrote to SES designers on how to avoid this state as well [using either shared key or signatures].

In short: I'll read both proposals again to revalidate/improve my discussion of this issue.

http://www.mhonarc.org/archive/html/ietf-asrg/2005-06/msg00033.html

-Doug














.


--
Best regards,

Amir Herzberg

Associate Professor
Department of Computer Science
Bar Ilan University
http://AmirHerzberg.com
Try TrustBar - improved browser security UI: http://AmirHerzberg.com/TrustBar Visit my Hall Of Shame of Unprotected Login pages: http://AmirHerzberg.com/shame
_______________________________________________
ietf-dkim mailing list
http://dkim.org