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

On Sep 26, 2005, at 1:33 PM, Amir Herzberg wrote:
> Douglas Otis wrote:
>
> > 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.

An abuser can easily implement DKIM or any other authentication and  
authorization scheme.  Authentication by itself provides little  
benefit.  Mailbox-domain authorizations alone provide even less, as  
this weak form of authorization is easily exploited.  However,  
authentication plus reputation would be able to curtail a major  
portion of spam/virus/phishing threats.
A labeling definition that categorizes unsolicited messages as not  
spam is _not_ useful.  The primary consideration regarding whether a  
message is abusive is whether permissions were granted by the  
recipient.  This consideration is especially important for bulk  
messages offering disproportionately greater value for the sender  
than recipients.
A "verified" label plays _no_ role in deciding whether a message is  
abusive.  A message that falsifies a header or label may be  
considered fraudulent, but current email practices allow unseen  
headers to be considered that of the sender, and do not define how  
prior headers are assessed.
A school using a T1 line for Internet access may be unable to  
accommodate ADV+DKIM messages and still achieve reasonable Internet  
access.  There is still cost associated with ADV+DKIM that you ignore  
when you claim there is a means to "filter" messages.  This  
"filtering" after the exchange still costs the recipient that has no  
desire to receive the messages.


> > 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`.

Laws allow any number of cases where labels may be bypassed.   
Fortunately, recipients may establish their own criteria of  
acceptable behavior.  For simple enforcement, labels MUST NOT be a  
criteria for bypassing a more general requirement of not sending  
unsolicited bulk email.

> >  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.

I can not imagine a label scheme that would safely disable anti-virus  
protections.  With respect to ads, either messages are desired and  
therefore are not a problem with or without a label, or they should  
not be sent.   Freedom goes both ways.  The recipient is equally free  
to say "No Abusers."  The recipient is free to depend upon a  
community assessment of abusive sources.  A label scheme attempting  
to offer a "consent variance" increases enforcement costs and  
therefore would be of _NO VALUE_.

> > 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.

What do you mean unproven assertions of a black-hole list?   The  
proof is whether messages were granted or unsubscribed.  A label or  
lack of a label has no bearing with respect to the nature of abuse.

> > > 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` .

A DKIM signature says this content has not changed and was  
"permitted" by the signing-domain.  DKIM offers a content label that  
actually has value, unlike the labeling you describe.

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

You have dismissed a risk by assuming the victim controls a  
compromised router.  DKIM in conjunction with DNSSEC offers a  
significant advantage for inhibiting such attacks.

> > 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?

A black-hole list is terminology for black-holing (creating a dead- 
end) for specific addresses emitting abuse.  One form of this list in  
BGP is called black-hole routes.  From a legal perspective, black- 
listing describes specific actions unrelated to black-holing.  Seek  
the advice of a lawyer for further clarification.

> > 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??
Unlike DKIM, path registration is really just server authorization  
provided by a mailbox-domain.  A domain owner using a provider that  
does not properly assert mailbox-domain constraints, are exposed to  
"intra-server" abuses by any other client of that provider.  After  
all, path registrations are public.  You mentioned the problem  
knowing which mailbox-address is even being checked.  This creates a  
similar problem at the outbound server as well.

> > Many MTAs 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.

You have two examples.  The PRA in Sender-ID and the SSP in  
conjunction with DKIM.  The PRA locates an authorized list of  
addresses; the SSP locates an authorized list of signing-domains.   
For various reasons, neither scheme follows SMTP 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.

As all mailbox-domain authorization schemes will fail in various  
cases, the mitigation involves leaving authorization open-ended,  
meaning the authorization never totally fails, but may result in the  
message being placed into suspense, a separate queue or folder.

> > Your "ALL" chart lists '+', where this could be seen as the   
> > "politically incorrect" mode.
> What do you mean by PC here?

While your explanation of the meanings could be derived from the  
drafts, this ignores risks associated with unfair reputations accrued  
against the mailbox-domain by various email plug-ins being  
announced.  By not PC, this '+' symbol would be the "middle-finger"  
defiance mode. : )  For SSP, there is the 'y' or the '~' mode instead  
of '~' and '?'.

> > 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.

Consider that crypto proposals (ignoring SSP) are more deterministic  
with respect to the I/O overhead.  Your statement then appears to  
assume there would be a type of white-listing that bypasses content  
filtering.  In the few cases where such bypassing might be safely  
avoided, there is not enough volume to justify the risk for making  
exceptions.

> >  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?

Although a database for domain names may be large and can grow  
without bounds, names provide a history and should cause less  
collateral blocking.  IPv6 offers the same potential increase in the  
size of the database.
From a cost standpoint, collateral blocking perhaps accounts for the  
majority of complaints related to listing services.  There is also  
the problem of Zombie systems using automated access to provider's  
servers where messages are sent an inch deep and a mile wide.  An  
opaque-identifier in conjunction with DKIM would be a powerful tool  
to combat this emerging threat.  It would also help distribute black- 
hole listing, as larger problematic domains could publish their own  
lists or perhaps delegate the zone to a specialized service provider.

> >  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?

I was reacting to the oversight of the risks associated with mailbox- 
domain authorization and the rather quick dismissal of value  
verifying the domain.  As example, in the HELO section, HELO  
verification offers significant value for DKIM or any other domain  
based authentication scheme from a resource protection standpoint.   
The alternative would fail-over to the remote IP address.  This of  
course assumes a domain based reputation scheme is available, in  
addition to the IP address black-hole list.
-Doug

_______________________________________________
ietf-dkim mailing list
http://dkim.org