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

From: Amir Herzberg <[email-masked]>
Date: Mon, 26 Sep 2005 22:33:28 +0200

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

_______________________________________________
Asrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/asrg