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