[ietf-dkim] Not exactly not a threat analysis
moore at cs.utk.edu
Tue Aug 16 21:02:40 PDT 2005
> Hmmn. I fear I see a lot of searching for our glasses under the
>> b) so that if Alice sends an advertisement to Bob, and Bob forwards
>> it to a large number of other addresses, it is clear that Bob, not
>> Alice is responsible for the messages forwarded by Bob.
> Bob is all at mycompany.com, a distribution list with a lot of names on
> it. Alice is Krazy Kevin, who looks for lists he can send spam
> through. Why is Alice off the hook here? I get tons of mail through
> distribution lists, including a lot of spam from Krazy Kevin back when
> he was sending spam rather than eating it, and I can't recall ever
> seeing a remailing joe job, so this is hardly a hypothetical
it's not a counterexample, it's just a different threat. it's also
an illustration of why you want to authenticate each submission
separately, along with the recipient list.
if Alice sends mail to lists that isn't appropriate for those lists,
we want the authentication to provide evidence that she's done this.
if Bob resends the same message to people who haven't asked to be on
his list, we want evidence of that also. the two cases are not
mutually exclusive, and we don't know a priori which case we need
(btw, I have seen something resembling a remailing joe job. I was
hired to solve a problem that a fairly well known bank had. the
bank's incoming mail gateway had a peculiar bounce format that would
replace the subject message's From field with the bank's address, add
another nonstandard header that essentially said this is a bounce
(but which no MUA bothered to display), delete all received fields,
and send the resulting message back to everyone in the To or CC field
of the subject message. (honestly, I'm not making this up). the
attacker was using this to send porn out and make it look as if it
was coming from the bank. this didn't appear to be ordinary spam -
there was no way to contact the seller - so it appeared to be an
attempt to discredit the bank.)
>> c) (maybe) so if Alice wants to send advertising to Bob with the
>> promise that she will pay Bob $1 for reading it, Bob cannot
>> distribute the message to N of his friends so that they'll each get
>> $1 also.
> Hmmn. Pay to read ads systems already exist, and they work by putting
> a unique URL in each message that you can only click once. Can we
> agree that this is not a problem that anyone has asked us to solve?
sure, we can discard that case.
>> I think things need to be as easy to understand as we can make them,
>> but not so simple that it misrepresents reality when there's an
>> important difference between cases.
> I think we're trying to define a scheme that provides a level of
> accountability that is useful for evaluating incoming mail, not
> something that captures the semantics of every possible relationship
> among a group of people.
that's not what I'm trying to do. I'm trying to make sure that we
don't design DKIM in such a way that it conflates different cases
that need to be handled differently, and also so that DKIM might
actually be useful against spam.
>>> Well, DKIM doesn't make it through this list unless you use l=
>>> and z=. :)
> We definitely had this argument before.
what's this "we" stuff, white man? we don't even have a WG yet and
you're trying to insist that this is already a settled issue?
> You cannot expect signatures
> to survive mailing lists (as opposed to courtesy forwards) unless you
> loosen the signing algorithm to the point that it will accept
> mutations that people wouldn't consider to be the same message, e.g.,
> adding new MIME parts.
well, the real world seems to be moving in the direction of doing
fairly arbitrary changes to messages even if you don't consider
mailing lists. consider the ongoing OPES work, for instance.
there's an inevitable tension here between the desire to authenticate
messages and the desire to filter out bogus parts and convert other
parts. it's not clear to me that the canonicalization stuff in
current DKIM is anywhere close to realistic.
anyway, we're going to have to have some way of resolving that
conflict and if DKIM wants to be successful it's probably not going
to be either "lists can't mung messages at all" or "lists invalidate
DKIM signatures". because it's too useful to be able to validate a
signature of a message that has been sent through a list, and it's
too useful for lists to be able to mung messages (though i'd be happy
to see less of this).
More information about the ietf-dkim