[ietf-dkim] Not exactly not a threat analysis

[Keith Moore]

> Hmmn.  I fear I see a lot of searching for our glasses under the
> streetlight.
>
>
>> 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
> counterexample.

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

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

Keith