Subject: [ietf-dkim] DKIM and mailing lists

From: Aumont - Comite Reseaux des Universites <[email-masked]>
Date: Wed, 18 Jan 2006 11:36:33 +0100

Hi

This message is about support of DKIM by mailing list software. Please 
excuse me if this topic as allready been discussed in this list (it's 
quite hard to read all the message from this list).

I think deployment of DKIM require a good support of DKIM by some of the 
major mailing list software. I am one of the author of Sympa mailing 
list software and I feel concerned by this.  What a mailing list manager 
must do with DKIM ?

 From my understanding, the minimum is to preserve existing 
DKIM-Signature: header and not modify the message in a way that will 
alter the signature.  For this issue, existing specification are quite 
clear (the difficulties are only related to headers that must be 
preserved where most availible libraries to modify message headers  
don't garanty headers  lenght line and headers order).

It will be also very powerfull to exploit DKIM signature as an 
authentication method when the context require to verify user privilege. 
This can replace email confirmation chalenge in many cases. This can be 
done also quite easily.

What are the other  issue related to mailing lists ? In which case the 
mailing list server need to apply it's own signature to a message ?

Serge Aumont

ps : internet2.edu is just starting a working group about mailing list 
and DKIM
 
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Jan 2006 11:38:56 +0000

Hi Serge,

> list software and I feel concerned by this.  What a mailing list manager 

I'll leave it for others who know more about mailing lists to give
you a detailed answer, but at the BoF in Vancouver a couple of people
made the good point that this WG should provide positive guidance for
mailing list managers (and I guess developers) on, e.g. how to preserve
DKIM signatures.

So I expect that we'll try to either get a section of our overview
deliverable or even a separate document written up on just this
topic. However, its a bit early yet as you can imagine - hopefully
that'll happen during/after the summer (all going well).

> ps : internet2.edu is just starting a working group about mailing list 

If there's a public archive, it might be good to post the URL
here once that's setup.

Cheers,
Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Jan 2006 04:46:17 -0800

On Wed, 2006-01-18 at 11:36 +0100, Aumont - Comite Reseaux des
Universites wrote:
> 
> From my understanding, the minimum is to preserve existing DKIM-
> Signature: header and not modify the message in a way that will alter
> the signature.  For this issue, existing specification are quite clear
> (the difficulties are only related to headers that must be preserved
> where most available libraries to modify message headers don't garanty
> headers length line and headers order).

Much of the requirements for a mailing-list will be determined by how
DKIM becomes exploited and what resulting defenses are crafted. 

> It will be also very powerful to exploit DKIM signature as an method
> when the context require to verify user privilege. This can replace
> email confirmation challenge in many cases. This can be done also
> quite easily.

There is a risk related to relying upon just the DKIM signature.  Any
cryptographic signature can be replayed.  Currently there is no
provision within DKIM to adequately deal with this problem.  One
strategy could be to not sign messages sent to mailing-lists unless they
are known to obfuscate the signatures and perhaps replace the signatures
with their own.  Should this strategy be used, then flattening of
messages and adding the normal changes could continue.

The From header may then need to have multiple addresses introduced,
where the first email-address would be that of the mailing-list.  It may
also require that the From email-address be moved entirely into the body
of the message and replaced with the email-address of the mailing-list.
Even changing the From header will mean simple strategies to kill-file a
participant will become more difficult.

> mailing list server need to apply it's own signature to a message ?

In my view, once DKIM is used as a basis for white-listing or basing
acceptance of messages, mailing-lists will quickly become taboo unless
the sender's signatures are obfuscated.  

<http://tools.ietf.org/wg/dkim>

Some of these ideas are explored in this draft:
<http://tools.ietf.org/wg/dkim/draft-otis-dkim-options-00.txt>

Many of these issues will remain open until further thought is given
regarding these threats.  These concerns are currently being addressed
by the document Jim is preparing.  It appears the appraisal may be
biased with a focus upon addressing the immediate problem of commerce
emails being phished.  Issues related to general use have been given
less weight in the balance.  Time will tell how well these concerns have
been considered.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Jan 2006 13:20:38 +0000

Doug, All,

> <http://tools.ietf.org/wg/dkim/draft-otis-dkim-options-00.txt>

Just a quick note in case anyone gets confused.

As of now, *none* of the I-Ds listed on the tools page [1]
are official DKIM WG drafts.

The next revisions to the threats [2] and base [3] drafts
will very soon become official WG documents, but the others
remain, for now, as individual submissions (and I'm not sure
how exactly they got listed on [1]).

Regards,
Stephen.

[1] http://tools.ietf.org/wg/dkim
[2] http://tools.ietf.org/wg/dkim/draft-fenton-dkim-threats-02.txt
[3] http://tools.ietf.org/wg/dkim/draft-allman-dkim-base-01.txt

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Jan 2006 16:53:59 +0100

Mr. Aumont,

> I think deployment of DKIM require a good support of DKIM by some of
> the major mailing list software. I am one of the author of Sympa
> mailing list software and I feel concerned by this.  What a mailing
> list manager must do with DKIM ?
>

My memory matches that of Stephen's that this was an issue raised in the
BoF, and that there was at least a tacit understanding that the matter
would be addressed by the working group.  I think there is already some
guidance in the base draft.

Thus far discussions seem to conclude along the following lines:

    * If a mailing list manager is going to mangle a message that was
      signed it SHOULD resign it.  This has all the UI problems that
      Doug mentioned in his message.
    * The original spec had a length attribute just so that the text of
      a message could be preserved while some sort of mailing list blurb
      could be added.  This is not a perfect solution.  For one, if a
      mailing list manager is too smart and attempts to modify
      multipart/alternative components, the game is lost because you
      have to delve deep into the message to do that.  Fortunately I
      don't know of mailing list software that does this.  Some guidance
      here would be useful.
    * Some guidance will need to be given about protection of the
      "Subject:", "Sender:", and any other headers that are protected. 
      This goes beyond mailing list maintainers.  If the signing domain
      protects either, then the mailing list system should be reticent
      to make changes.  But should the signing domain sign these things
      in the first place?

Eliot

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Jan 2006 16:59:26 +0100

Stephen Farrell wrote:
 
> *none* of the I-Ds listed on the tools page [1] are official
> DKIM WG drafts.

Yes, they'd start with draft-ietf-dkim-*.  Besides you'd know
if you or Barry approved the -00 and appointed the editors.

> the others remain, for now, as individual submissions (and
> I'm not sure how exactly they got listed on [1]).

"Tools" magic, the file names contain "-dkim-".  It's in the
subsection "related documents", all official drafts will show
up in subsection "active" (or "expired") before "related".  Bye

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 18 Jan 2006 16:51:08 +0100

Douglas Otis wrote:
 
> The From header may then need to have multiple addresses
> introduced, where the first email-address would be that of
> the mailing-list.

NAK.

> It may also require that the From email-address be moved
> entirely into the body of the message and replaced with the
> email-address of the mailing-list.

NAK.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Jan 2006 10:20:29 -0800

On Jan 18, 2006, at 7:51 AM, Frank Ellermann wrote:

>> introduced, where the first email-address would be that of the  
>> mailing-list.
>
> NAK.

This consideration depends upon:

1) When replay abuse becomes a serious problem, the defensive  
reaction of obfuscating signatures by the MDA or mediator also means  
not altering the message is not a solution.

2) When an SSP policy associated with the From email-address  
increases the rating of a message, publishing closed polices may  
become a necessary defense.

Modifying the message is already a common practice by list-servers  
and resigning a modified message may not overcome restrictions  
imposed by a From email-address policy.

In the dkim-options draft, rather than restricting an email-address,  
the goal was to identify unique sources and highlight recognized  
correspondents.  This included the ability to assert a signing role  
such as mediator, as in the case of a list-server.  Adding a signing  
role avoids difficulties in classifying the nature of the source and  
may squelch conflict notifications.

>> It may also require that the From email-address be moved entirely  
>> into the body of the message and replaced with the email-address  
>> of the mailing-list.
>
> NAK.

This would be a follow-on of the closed policy issue when dealing  
with message changes.  There has been a suggestion that all From  
email-address be checked against a policy to determine the most  
restrictive policy.  This would then mean adding multiple From email- 
addresses would not be a solution for avoiding policy restrictions.

If a message sent to a list-server opted to not include the Subject  
header as a means to increase compatibility, then instantly these  
messages become a way to send subject line spam.  When messages use a  
body-length to increase compatibility with list-servers, then again  
instantly these messages become a way to send spam.  Of course, any  
abusive message replay could hurt the reputation of the individual  
sending to the list.  A defensive posture in reaction to this problem  
may be to exclude signatures when sending to a list-server or ask the  
list-server to remove or obfuscate incoming signatures.  Resigning  
and obfuscation of incoming signatures would preserve valuable  
information and dramatically reduce potential sources for message  
replay abuse.

-Doug

---

From: John Levine <[email-masked]>
Date: 18 Jan 2006 21:24:20 -0000

>list software and I feel concerned by this.  What a mailing list manager 

This is a rather contentious point.

One model which we might call the "thin" model considers mailing lists
to be essentially mail forwarders, so the identity of the mail is that
of the original sender.  This encourages list software to minimize the
changes they make to mail on the way through to avoid breaking the
signature, and perhaps to add its own signature on the way through.
IIM had a few hacks intended to help this, a length to tell the
recipient that the signature doesn't cover all of the message, and
duplicated headers so that it can log what, e.g., the Subject line
said before the list added a [listname] tag.  I've never seen a
persuasive description of what recipients are supposed to do with
mismatched subject lines and chunks of unsigned trailing material but
I expect people who think it's a good idea can explain it.  Another
way to be sure the signature stays intact would be to encapsulate
every incoming signed message like a one-message MIME digest, but list
reading users would probably not enjoy that.

The other "thick" model considers the mailing list to be the
originator of the message.  In this model, the list software would
strip off the signature from the incoming message, do whatever it does
to the message, and re-sign it on the way out.  This better matches
modern list software that does things like reordering and deleting
MIME parts and flattening HTML to plain text.  There are a variety of
plausible things it might do with the inbound signature, ranging from
discarding it (on the theory that it's the list's reputation that
matters for list mail, not the reputation of the contributors) to
using a proposed header to log the fact that the inbound message had a
good signature, and signing that.

Depending on your view of what a list is and the way your list
software works, you could try and implement either of these.  One
thing I can definitely promise is that people will have religious
beliefs as deep and irrational as the ones they have about Reply-To:
headers, so no matter what you do, you can be sure that someone will
tell you that you are an idiot for not doing it his way.

R's,
John

---

From: Mark Delany <[email-masked]>
Date: Wed, 18 Jan 2006 22:17:27 +0000

> software works, you could try and implement either of these.

Given the religion, I wonder whether both are entirely reasonable and
leave the choice to the particular list implementor.

Mark.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 18 Jan 2006 23:38:53 +0100

> leave the choice to the particular list implementor.

I know I don't want to take on the argument of which is reasonable so
applying guidance for both and for clients in the face of both is
important.  Particularly for whether or not you protect the Subject line
and how at all to limit length, and or resign.  There are some serious
UI issues there.

Eliot

---

From: John Levine <[email-masked]>
Date: 18 Jan 2006 22:52:40 -0000

>leave the choice to the particular list implementor.

Sure.  I imagine that after a while it will become apparent which is
more useful.  I have my suspicions about which that will be, but I'm
not confident enough of them to tell people not to try other
approaches.

R's,
John

---

From: Mark Delany <[email-masked]>
Date: Wed, 18 Jan 2006 22:59:26 +0000

> and how at all to limit length, and or resign.  There are some serious

The very early thinking back at DK-00 was that a participating list
might sign List-ID. The idea being that List traffic is distinctly
different and that a verifier/UA might sensibly treat such traffic
differently in the presence of a List-ID. Subsequent revisions went
down the path of generalizing that to Sender.

In retrospect, I'm not sure I'm a fan of that generalization as List
traffic is so different that it need not be squeezed into a
generalized category that otherwise is almost completely absent in
real-life traffic.

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Jan 2006 15:52:55 -0800

>down the path of generalizing that to Sender.
The basic problem is that mailing lists are for all intents and purposes
forging content when they don't change the From address but insist
on adding trailers and subject line changes, blah, blah, blah. The best
would be for them to stop doing that, but in an imperfect world we're
going to be left with several unpleasant choices. John seems to be
characterizing that as "religious", but I think of it as wanting to have
some semi-viable options short of demanding a flag day and going
away pouting.

Regardless of what the absolute numbers are, they are a significant fraction
for the people who will be pounding out these standards. Or vetoing them.
I'm all for not spending needless time on turd polishing, but I doubt its
an option to present a rough-hewn turd either.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 18 Jan 2006 16:08:14 -0800

On Jan 18, 2006, at 2:17 PM, Mark Delany wrote:

> Given the religion, I wonder whether both are entirely reasonable  
> and leave the choice to the particular list implementor.

When DKIM signatures are used in conjunction with acceptance  
assessments, how are compromised systems within the AdmD or message  
replay abuse handled?

Large domains and list-servers may become a major component of a  
message replay abuse problem.  Access to a valid signature should be  
made increasing difficult to suppress the emergence of a replay abuse  
problem.  When the administrator is informed there is a problem,  
there should be an ability to squelch the problem quickly.  To be  
effective, this may require questionable messages receive special  
dispensation.   The "thick" model, as John describes it, appears the  
most amenable for offering a solution.  A general strategy for  
dealing with the replay abuse problem may be to adopt an overlay MDA  
signature with the obfuscation of the MSA/MUA and mediator  
signatures.  A single character offering "binding advice & signing  
role" added to the signature can simplify several aspects of this  
situation.  Indicating the role of the signer also allows a strategy  
to ensure only a reasonable number of signatures are retained.

-Doug

---

From: John Levine <[email-masked]>
Date: 19 Jan 2006 01:07:59 -0000

> The basic problem is that mailing lists are for all intents and
> purposes forging content when they don't change the From address but
> insist on adding trailers and subject line changes, blah, blah,
> blah.

I don't find "forging" to be a useful description of what mailing
lists do.  It's true, they send mail from someplace other than the
normal place associated with the From: address, but that's no more
forgery than my sending a postcard on vacation with my normal return
address but funny foreign stamps and postmarks.  It's also not the
only situation where a third party sends legitimate mail on someone's
behalf, with another familiar example being the mail-an-article
feature on newspaper sites.

I have several hundred small business users that receive mail
addressed to their various company domains hosted here.  Although I
provide outbound SMTP relay service, maybe half use it and the other
half just send through their own ISP accounts, so mail for those
domains goes out through Road Runner, Verizon, and a dozen other
little ISPs you never heard of.  Would a DKIM signature match the
From: address?  Not likely, it's all they can do to get their POP
accounts set up, so their ISPs will sign it.  But it's not forged.

Our lives would be simpler if everyone would mail only in ways that
matched our favorite simple security model, but disparaging real mail
sent in inconvenient ways as "forging" isn't going to make that
happen.

R's,
John

---

From: <[email-masked]>
Date: Wed, 18 Jan 2006 20:14:40 -0500

What is a mailing list? To me it is a script driven reply to all central repository. Sounds like a resigning requirement but since I neither design nor manage one twill leave it up to the market.
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Mark Delany
Sent: Wed 1/18/2006 5:59 PM
To: [email-masked]
Subject: Re: [ietf-dkim] DKIM and mailing lists

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 18 Jan 2006 17:38:14 -0800

John Levine wrote:
> lists do.  

Then try "indistinguishable from forging".

> It's true, they send mail from someplace other than the
> address but funny foreign stamps and postmarks.

Speaking of unuseful descriptions... a more apt analogy would be
for the Ugandan Post Office adding a bunch of content obfuscating
the fact that you'd been thrown in the klink. The point is that
from a receiver's standpoint there's no difference when that
happens. With DKIM, you can at least tell what was added and
what wasn't in some cases.

> It's also not the

I don't argue about the utility, but there are also a lot of
indistinguishable abuses as well. It would be nice to have
a means to be a Well Behaved Mangler, and I think there's
provision within the spec to achieve that at least in some
common cases. Whether that's enough is debatable of course,
but anything that predicates a flag day is a dead letter.

My suspicion is that couching this in terms of "right"
and "wrong" approaches is exactly the wrong thing to do here
because it factors out the timing aspect: as in, "right
solution at the right time". We need to get over one hump
at a time.

		Mike

---

From: "John R Levine" <[email-masked]>
Date: 19 Jan 2006 01:06:12 -0500

> Then try "indistinguishable from forging".

I dunno about you, but I have little trouble telling mailing list mail
from random forgeries when I look at it.

If your favorite anti-spam technique or security model behaves badly when
presented with list mail, I would consider that to be a flaw in the model
rather than blame people for using mail in a way that has been common and
productive for about 30 years.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"I shook hands with Senators Dole and Inouye," said Tom, disarmingly.
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 19 Jan 2006 10:16:35 +0100

John Levine wrote:

> Our lives would be simpler if everyone would mail only in
> ways that matched our favorite simple security model

Sure, but where some practice is far beyond anything found
in an RfC it's okay to say "broken".

> disparaging real mail sent in inconvenient ways as "forging"
> isn't going to make that happen.

Foul-ups in what I consider as "user territory" like the body
(content), Message-ID, From, Sender, Reply-To, Subject, Date,
and any Resent-zoo are a bit more than only "inconvenient".

I'd have no problem with s/forgery/broken/, but "inconvenient"
is way too weak.
                           Bye, Frank

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 19 Jan 2006 10:57:41 +0100

Douglas Otis wrote:

> Modifying the message is already a common practice by
> list-servers and resigning a modified message may not
> overcome restrictions imposed by a From email-address
> policy.

Then it's not more the original message, they could send
it as "digest" (multipart/digest, a single message/rfc822,
or maybe some kind of application/mbox) or resend it with
their own Resent-* header fields, above all with their
own Resent-Message-ID.

Substantially different messages need different Message-IDs,
otherwise it breaks horribly (e.g. in mail2news scenarios).

> Adding a signing role avoids difficulties in classifying
> the nature of the source

There's no need to sign a message that is already signed as
long as it's still the same message.  If it's some kind of
"derived message" see above.  For the clumsy Resent-* cases
they could remove the old signature.  Or we could offer some
Resent-DKIM header field.  Or "we" decree that Resent-* is
"out of scope" for all kinds of DKIM-signatures.

>>> entirely into the body of the message and replaced with
>>> the email-address of the mailing-list.

> This would be a follow-on of the closed policy issue when
> dealing with message changes.

If what you're talking about is the "use digest or Resent-*
for modified messages" case, then the old From could be in
fact moved into a complete message/rfc822 part (for digests).

Its DKIM signature (incl. any signing policy) would still
work perfectly for this message/rfc822 part.  "We" (TINW)
better make sure that it also survives in application/mbox.

That should cover all cases of "digest mode".  No need to
manipulate the From-header for mailing lists.  The worst
case is PRA and its Resent-zoo.

But mailing lists wishing to be PRA-compatible are already
in deep sh*t, and it's no DKIM-issue that PRA breaks Sympa-
lists.  We discussed this 18 months ago in MARID.  [See also
<http://www.ietf.org/IESG/APPEALS/?C=M&O=D> for those who
don't know this, Sympa and Yahoogroups are famous examples]

But nowhere will DKIM force mailing lists to "forge" the From
header field, "we" just won't let it pull this stunt.  That's
a new WG in the security area, "we" are not working on orders
from Redmond.
                         Bye, Frank

---

From: John Levine <[email-masked]>
Date: 19 Jan 2006 15:49:04 -0000

>in an RfC it's okay to say "broken".

I feel like I'm in the twilight zone here.  E-mail mailing lists have
been around for over 30 years, and have been mutating and remailing
messages just as long.

Does anyone really think that DKIM can set rules about the way that
existing mailing lists can run, and get any response other than
derisive laughter?  Lists exist today, DKIM doesn't, and if DKIM is
going to be useful, it better deal with the way that lists actually
work.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Jan 2006 17:03:41 +0100

John,
> going to be useful, it better deal with the way that lists actually
I agree.

We should expect, however, that DKIM will become increasingly more
useful as mailing lists and UIs adopt whatever changes the documents
recommend.

Eliot

---

From: Aumont - Comite Reseaux des Universites <[email-masked]>
Date: Thu, 19 Jan 2006 17:44:01 +0100

John Levine wrote:

>derisive laughter? 

The problem is that mailing list are not described by any RFC. That's 
one of the reasons why so many mailing list manager exists and your are 
right, many mailing list software will not deal DKIM-Signature according 
to DKIM RFC specification.

Is this a good reason why some hack are added in DKIM ? The lengh spec 
in DKIM-Signature seems intended for old dirty mailing list software to 
be able to add some message trailer without alteration of the signature. 
We known that it will be source of problems (it make the replay attack 
more sensible) but in any way such mailing list software will probably 
brake the signature for many other reasons (change in headers for example).
Such arrangment will make life harder for thoses who wants full 
compatibility with DKIM, why not remove this facility ?

Sympa (and probably a few other mailing list managerd) is allready ready 
for S/MIME signature (it test if the message is signed, and don't  
modify the message body by any way) . It can be adapted for DKIM doing 
all what is required (for exemple testing if the subject is signed 
before adding [LISTNAME] tag in it etc.
 I think it is reasonnable to specify what mailing list MUST do.

Serge Aumont

---

From: Jim Fenton <[email-masked]>
Date: Thu, 19 Jan 2006 09:58:49 -0800

Aumont - Comite Reseaux des Universites wrote:
> one of the reasons why so many mailing list manager exists and your
> are right, many mailing list software will not deal DKIM-Signature
> according to DKIM RFC specification.
As someone pointed out earlier, there are two kinds of mailing lists: 
those that modify the message and those that don't.  By "modify" here I
mean any changes to the body and to any of the signed headers.  Adding
additional headers isn't considered a "modification" in this context
(unless the signature is constructed to prevent the header from being
added).

Here's how I think it should work:

Lists that don't modify the message MAY re-sign it.  They SHOULD NOT
remove the original signature, because its validity has not been
affected and it provides useful information.  Verifiers MAY consider the
original signature or the list signature (subject to Sender Signing
Practices) in deciding what to do with the message.

Lists that do modify the message SHOULD re-sign it.  They MAY remove the
original signature, because it is probably invalid anyway.  Verifiers
MAY consider the list signature in the handling of the message.

I believe that signatures from lists (and other third-parties) will be
more dependent on reputation and accreditation (and local white lists
and black lists).  This is because third-party signatures allow messages
to be signed by anyone, not just the originator's domain, so it's more
important to have some information indicating that the third party is
reliable. Domains that host many reliable lists, like ietf.org, imc.org,
mipassoc.org, yahoogroups.com, etc. as well as those that operate other
third-party signing applications (evite.com, nytimes.com, ...) will
generally be whitelisted.  But it will be very easy for attackers to
apply third-party signatures from throwaway domains so domains with
little reputation will have difficulty getting their third party
signatures accepted.  This isn't a characteristic of DKIM, but is a
characteristic of how I expect it will be used in a few years.

Lists MAY decide to sign a header indicating whether the message they
received was signed.  I'm not entirely sure how that would be used,
however.  As is currently the case, lists can use whatever criteria they
want to decide whether to propagate an incoming message:  whether the
>From address corresponds to an address on the list, for example. 
Likewise, I can imagine that some lists might eventually require DKIM
signatures in order to propagate messages (or bypass moderation); it's
entirely up to them.  I have a little trouble imagining that they might
sign some messages and not others: why would they propagate a message at
all when they don't have enough confidence to sign it?

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Jan 2006 10:33:28 -0800

On Jan 19, 2006, at 1:57 AM, Frank Ellermann wrote:

> Then it's not more the original message, they could send it as  
> "digest" (multipart/digest, a single message/rfc822, or maybe some  
> kind of application/mbox) or resend it with their own Resent-*  
> header fields, above all with their own Resent-Message-ID.
>

The list-server would be one example of where mediators normally  
utilize the email-address of the initial author.  For many  
recipients, this is what they expect to see.  While some view this as  
an attempted forgery, many legitimate services will have a different  
view.  You could be right about encapsulating messages, but that  
represents a fair amount of change.  This may produce ugly text for  
some MUAs, and may break the reply mechanism.  One of the reasons for  
implementing DKIM was to maintain transparent security, but to handle  
this clumsy and broken SSP From restriction, DKIM becomes far from  
remaining transparent.

Adding a role to the signature would allow the source of From headers  
to be treated differently.  From a security aspect and a replay  
concern, the message should have the incoming signature removed and  
replaced by an MDA signature, where the role of the signature is also  
important.  When the message is submitted, any MDA signature must be  
removed and the MSA or mediator signature would be added.  When the  
recipients are defined by the initial sender, both the MSA and  
mediator signatures could appear when the message has not changed.   
When the message is changed, the MSA signature should be obfuscated  
by a "!Verified"/"!Invalid"/"!Unknown" statement that indicates  
whether it had been verified or not and included within the mediator  
signature.

There is no reason why separate assertions can not be made with  
respect to whether a mediator is permitted to remain transparent.  It  
is a major error in judgement to base security upon what the  
recipient _may_ see.  A recognition scheme could easily handle MSA/ 
MUA signatures differently from those of mediators, and ensure only  
those messages registered using an initial "out-of-band" method of  
identification are highlighted or marked.

This binding approach replaces the third-party trusted-certificate  
scheme that Phillip suggests, where even when a certificate is  
trusted, there is still no assurance what the user sees.  Registering  
the source of the message by the recipient offers perhaps the only  
safe method where messages can be highlighted or marked in some  
manner that could be safely communicated to the recipient.  Commerce  
sites getting phished only need to add a DKIM signature.  Filters  
will need to look at much more than the From header to abate phishing  
scheme.  SSP offers little _if any_ additional protection.  Any  
indication a message conforms to some SSP requirement will only serve  
the interests of the bad actors.

>> Adding a signing role avoids difficulties in classifying the  
>> nature of the source
>
> There's no need to sign a message that is already signed as long as  
> it's still the same message.  If it's some kind of "derived  
> message" see above.  For the clumsy Resent-* cases they could  
> remove the old signature.  Or we could offer some Resent-DKIM  
> header field.  Or "we" decree that Resent-* is "out of scope" for  
> all kinds of DKIM-signatures.
>
>> with message changes.
> If what you're talking about is the "use digest or Resent-* for  
> modified messages" case, then the old From could be in fact moved  
> into a complete message/rfc822 part (for digests).

I guess the question that would then need to be raised, would this  
digested message approach fly.  This approach makes OpenPGP and S/ 
MIME look more attractive.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Jan 2006 10:48:44 -0800

On Jan 19, 2006, at 9:58 AM, Jim Fenton wrote:

> I believe that signatures from lists (and other third-parties) will  
> be more dependent on reputation and accreditation (and local white  
> lists and black lists).  This is because third-party signatures  
> allow messages to be signed by anyone, not just the originator's  
> domain, so it's more important to have some information indicating  
> that the third party is reliable. Domains that host many reliable  
> lists, like ietf.org, imc.org, mipassoc.org, yahoogroups.com, etc.  
> as well as those that operate other third-party signing  
> applications (evite.com, nytimes.com, ...) will generally be  
> whitelisted.  But it will be very easy for attackers to apply third- 
> party signatures from throwaway domains so domains with little  
> reputation will have difficulty getting their third party  

The bad actors will have absolutely no trouble sending their spam  
through a list-server that is generally white-listed.  Yahoogroups  
have lists where participants are in the millions.  Once the bad  
actor reclaims their message, perhaps from the archive, they can then  
replay these spams world-wide and take advantage of the sterling  
reputation of the list.  How long will it be before that list's  
reputation becomes less than sterling?

A reputation service will have an inordinate effort sending out all  
the collected bad signatures attempting to keep ahead of all those  
messages sent through list-servers or via compromised systems in  
large domains.  Senders and recipients needs to play a role in  
squelching this problem.  Senders need to keep track of where they  
sent abused messages that are being replayed and block-list those  
recipients.  Recipients wishing to keep from being block-listed would  
then ensure no user ever sees a valid incoming signature, but instead  
replaces these signatures with an MDA signature.  When done  
universally, the sources for replay abuse should be reduced to a  
point where efforts to contain the problem are not overwhelmed.

-Doug

---

From: Earl Hood <[email-masked]>
Date: Thu, 19 Jan 2006 13:25:16 -0600

(Sorry if what I say has been said, catching up on list mail)

>       to make changes.  But should the signing domain sign these things

Mutation of header fields can be dealt with if the signer is able
to save the contents of the fields it signs, and those saved versions
are what is used during verification.  Verifiers can then restore
the save versions if verification passes.  Currently, DKIM does not
support this, and the saving capibility is limited.

You do get into problems if multiple signatures exist where a
given header field is different for each saved version for each signature.
Such descrepencies could be dealt with if role information is provided.

--ewh

---

From: Eliot Lear <[email-masked]>
Date: Thu, 19 Jan 2006 20:35:44 +0100

Douglas Otis wrote:
> have lists where participants are in the millions.  Once the bad actor
> reclaims their message, perhaps from the archive, they can then replay
> these spams world-wide and take advantage of the sterling reputation
> of the list.  How long will it be before that list's reputation
> becomes less than sterling?
I think this is as it should be.  If bad actor makes it on the list in
the first place, then list isn't doing a good enough job of validating
its members as good actors.

Eliot

---

From: Earl Hood <[email-masked]>
Date: Thu, 19 Jan 2006 14:19:39 -0600

> imposed by a From email-address policy.

I wonder if there are any legal ramification of modifying messages.
It is common for list software to modify messages, but one could
consider this a violation of copyright law.  If DKIM gets deployed,
legal ramifcations may become more probable.

> may squelch conflict notifications.

Would specifying which field a signature is asserting a role against
be sufficient?  For example, an originating domain may assert against
the originating header fields From, Sender, and/or Reply-To.  A mailing
list could assert against the List-ID and possibly any other List-*
header fields.

Note, this does not preclude a signer from including any header field
in the signature.  The role assertion only designates which header
fields it is applying a role to.  This way, a mailing list can add
a signature w/o interfering with any SSP of an originator.

Taking the way SSP is defined now, it only needs to be examined
wrt the From field if a signature asserts a role against it.  I.e.
Assertions against a known originating field (as defined in RFC-2822)
warrant an SSP check.  This will allow domains to apply DKIM signatures
on messages without worrying if the domain associated with the
originating address disallows third-party signatures since such signatures
contain no assertion against an originating header field.

Note, this does not address your [Doug] overall concerns about SSP,
but only the security problems of allowing third-party signatures as
SSP is currently defined.

--ewh

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Jan 2006 14:06:32 -0800

On Jan 19, 2006, at 11:35 AM, Eliot Lear wrote:
>> actor reclaims their message, perhaps from the archive, they can  
>> then replay these spams world-wide and take advantage of the  
>> sterling reputation of the list.  How long will it be before that  
>> list's reputation becomes less than sterling?
>
> I think this is as it should be.  If bad actor makes it on the list  
> in the first place, then list isn't doing a good enough job of  
> validating its members as good actors.

Most lists confirm the email-address by mailing back a link to verify  
that the participant indeed receives email at that email-address and  
wishes to subscribe to the list, a double op-in.  Will participants  
on a list need to have their own certificate?  You seem to be  
validating Phillip's concept of using trusted certificates rather  
than DKIM's self issued public keys.

Bad actors only need to post one message to then replay that message  
without limit within the delivery timeframe.  This problem will exist  
for any large domain, where many compromised systems will do the same  
thing.  Outbound filtering will not prevent this problem either.  If  
the reputation of the signature has value, then the sender should be  
careful where they send it, and likewise the recipient should be  
careful who is allowed to see it.  An overlay of the incoming  
signature by an MDA signature clearly indicating its role would  
ensure the message could never be used in a replay.  An overlay  
practice does not involve the creation of a difficult establishment  
of trust mechanism with anonymous list-participants.  DKIM was  
attempting to avoid this problem.  By limiting possible sources for  
replay abuse, bad actors can be identified by where they send the  
messages for replay.

Sender beware.  If it were to become common practice to overlay or  
remove the DKIM signature upon delivery, then the number of sources  
that would need to be listed as a replay risk would quickly become  
diminishing few, well within the timeframe where DKIM has acceptance  
value.  DKIM as a basis for acceptance ensures abusive message replay  
will be prevalent without mitigating mechanisms.  Chasing after  
millions of signatures of replayed messages will overwhelm any  
protective services.  It may become common practice to selective sign  
or not send messages based upon the destination.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 19 Jan 2006 15:13:51 -0800

> legal ramifcations may become more probable.

On the contrary, if not obfuscating the signature causes harm when  
used to abuse the reputation of the list participant, then perhaps  
that would provide a basis to claim damages.  Of course a list can  
issue any AUP they desire, but the general design should be safe.   
Not obfuscating the signature is not safe.

>> In the dkim-options draft, rather than restricting an email- 
>> address, the goal was to identify unique sources and highlight  
>> recognized correspondents.  This included the ability to assert a  
>> signing role such as mediator, as in the case of a list-server.   
>> nature of the source and may squelch conflict notifications.
>
> Would specifying which field a signature is asserting a role  
> against be sufficient?

Not as DKIM is currently specified.  The single character "binding  
and role" assertion in the dkim-options draft can be added to the  
signature and would be upwardly compatible with the current scheme.   
The role could even impose which headers are allowed to be associated  
with the signature, as suggested.

> Note, this does not preclude a signer from including any header  
> field in the signature.  The role assertion only designates which  
> header fields it is applying a role to. This way, a mailing list  
> can add a signature w/o interfering with any SSP of an originator.

On the contrary, SSP interferes with the normal use of the From  
header. : (

> Taking the way SSP is defined now, it only needs to be examined wrt  
> the From field if a signature asserts a role against it.  I.e.  
> Assertions against a known originating field (as defined in  
> RFC-2822) warrant an SSP check.  This will allow domains to apply  
> DKIM signatures on messages without worrying if the domain  
> associated with the originating address disallows third-party  
> signatures since such signatures contain no assertion against an  
> originating header field.

I am not sure I understand this statement.  The SSP needs to be  
checked when the signature does not conform to the domain found in  
the From header email-address, perhaps just the first or all.  (Not  
just when there is no signature as some have suggested.)  Those who  
are hoping what _may_ be visible to the recipient is being checked  
will not want conformance based upon any other header.  Of course,  
what is visible remains within the control of the sender, social  
engineering is a practiced art, and where native languages are being  
used, any protection offered by this scheme remains highly dubious.   
I am sure any phishers listening were delighted by the suggestion  
conformance could be signaled to the recipient.  : o

> but only the security problems of allowing third-party signatures  
> as SSP is currently defined.

If a commerce site felt better about publishing a SSP record of  
'o=!', there is no underlying problem with that concept, except it is  
really painful to find this policy amongst millions of other domains  
that still want to use list-servers, e-invites, etc.  Most domains  
make exceptions for large domains because of the constant background  
of abuse coming from their servers.  When DKIM becomes a basis for  
acceptance, that background noise will be amplified a billion fold by  
a replay strategy.  It is also nonsense to suggest that list-servers  
should be held to a higher standard than most large domains.

Jim just suggested that some protection can be achieved using an open- 
ended policy that excludes unsigned messages.  Beyond the issue where  
messages are modified by a list-server and treated as unsigned,  
signed messages may then quickly become the next spam-validating  
commodity.

Not to be critical, but too many decisions have been made from the  
perspective of being a big domain.  For them, recipients want to  
quickly identify these domains to white-list them so they are not  
disrupted by a block-list.  It is like the driver that throws away  
their rear-view mirror because they are the fastest thing on the  
road.  For all those smaller domains, the concerns are much  
different.  What happens when bigdomain.com increases the ratings for  
messages with an email-address policy?  The email-address is then  
assessed for abuse, regardless whether the policy is open-ended or  
not.  Heck, different types of policies are not a problem that  
bigdomain.com ever sees.

-Doug

---

From: John Levine <[email-masked]>
Date: 20 Jan 2006 03:26:39 -0000

>legal ramifcations may become more probable.

May I encourage members of the DKIM list not to play lawyer?  There is
a mountain of statute and case law about copyright and derivative
works.  Modified messages are not a new issue, either in general, or
in connection with e-mail, and a few extra virtual postmarks are not
going to break any legal ground.

R's,
John

---

From: John Levine <[email-masked]>
Date: 20 Jan 2006 03:35:59 -0000

> Mutation of header fields can be dealt with if the signer is able to
> save the contents of the fields it signs, and those saved versions
> the save versions if verification passes.

You could write software that did that, but I have never seen a
plausible scenario where it'd be useful.

How many mailing lists do you subscribe to where you need to do spam
filtering on the mail that comes through the list?  Me neither.  (I do
bozo filtering, but the bozos are neither spammers nor forgers, just
bozos, and I filter on their From: lines.)

If bad guys try to turn the clock back to 1995 and use mailing lists
as spam amplifiers, the solution will be the same it was ten years
ago, to fix the list software to keep the bad guys out, not to do
filtering at the recipient end.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Fri, 20 Jan 2006 05:44:25 +0100

Doug,
> wishes to subscribe to the list, a double op-in.  Will participants on
> a list need to have their own certificate?  You seem to be validating
> Phillip's concept of using trusted certificates rather than DKIM's
> self issued public keys.
That's not really where I was going.  What I more envision is that a
mailing list will have its own reputation that will match the LCD of the
list, just as you say, but that the way to protect against that is for
lists to be at least a little picky about who they allow on.  After all,
we've said that dkim is just a part of the solution, and we've indicated
that reputation systems are important (albeit out of scope for this
group), so why not let them address this problem as well?

> remove the DKIM signature upon delivery...
The ONLY time one removes a signature is when one breaks it.

Eliot

---

From: Mark Delany <[email-masked]>
Date: Fri, 20 Jan 2006 06:35:51 +0000

> The ONLY time one removes a signature is when one breaks it.

Eliot I agree with all of what you say, particularly the philosophy of
keeping list participation cheap and simple.

On the matter of breaking signatures, I think that mantra #1 is that a
broken sig is the exact equivalent of no sig therefore we need not
impose the task of sig removal on any party.

Given mantra #1, I think we can give Lists very simple guidance:

 o preferably use DKIM to verify submissions
 o add List-ID - as all good Lists are doing now
 o DKIM sign the content so as to include List-ID

Verifiers should first process the "outer" signature of the List and
assuming that verifies, take the List delivery path.

Additionally a verifier might wish to attempt verification of the
"inner" signature, and if that verifies they may be able to add some
value. For the services I'm involved with, I would not do this step,
but I understand that others find this of value. Rather, I would
manage knowledge of which List-IDs the recipient has subscribed to and
regardless of anything else, email with a List-ID would be delivered
to a "List" Folder in the absence of more specific instructions.

The point about all this is that the List does not involve itself in
the matter of the original author and the final receiver. If the
original author sig happens to survive then the final receiver can add
value if they choose to - but it's not a matter for the List to
consider one way or the other. In short, Lists can be lazy and I'm
guessing they'll like that. This also happens to be what a lot of
Lists will do today with no changes in code.

Some have talked about a List verifying the submission and adding a
header that claims they made the DKIM verification. This delegated
trust approach bothers me and seems contrary to the fundamental
concept that a final receiver can determine all authentication matters
independent of intervening parties. I call this mantra #2 - trust no
one but yourself.

All of which delves into the contentious issue of multiple valid
signatures - on that note, I'll abstain for now apart to suggest that
valid multiples only seem to make sense when viewed as a hierarchy.

Mark.

---

From: Graham Murray <[email-masked]>
Date: Fri, 20 Jan 2006 07:10:16 +0000

Douglas Otis <[email-masked]> writes:

> Those who are hoping what _may_ be visible to the recipient is being
> checked will not want conformance based upon any other header.  Of
> course, what is visible remains within the control of the sender,

Surely not. What is visible is controlled by the recipient and the
recipients mailer software. For example, with the mailer I use I can
(and have) configure it to show or hide whichever headers I choose and
can also (with a single button press) display all the headers. I admit
that not all mailer software makes it that easy, but the mailer
software used is under the control of the recipient not the sender.
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Aumont - Comite Reseaux des Universites <[email-masked]>
Date: Fri, 20 Jan 2006 11:22:15 +0100

Lets try to identify the different possible cases when a signed message  
is received  by the mailing list server. There are 3 actions that the 
mailing  list server can do :

- 1/./. : Add a mailing list server signature or not
- ./1/. : Remove existing signature or not
- ././1 : Modify the message in a way that breaks DKIM signatures or not

So we must examine benefits and problems for 8 cases :

------------------- 0/0/0 :
 -The list server does not add a signature/
 -does not remove the existing signature /
 -does not modify the message /
       
The message is distributed with a valid signature. The original sender 
reputation will be used by final RCPT to evaluate the message : the 
mailing list server is transparent forwarder but final receipient can't 
use DKIM signature in order to prove that the  message was relayed by 
the list.

------------------- 0/0/1
 -The list server do not add a signature/
 -do not removes the existing signature,/
 -modify the message,/

BAD : the message is distributed with invalid signature, this valid 
message will probably be suspicious for many rcpt

------------------- 0/1/0 and 0/1/1
 -The list server does not add a signature/
 -removes the existing signature, /
 -does not modify the message or not
 
The message is distributed unsigned.
If the sender SSP specifies  that all messages from this sender must be 
signed then this message is suspicious.

------------------- 1/0/0
 -The list server adds a signature.
 -does not remove the existing signature,/
 -does not modify the message

A) the mailing list server adds a signature i= (signer) and "From:" are 
different. The signature may be invalid if the sender SSP does not allow 
third party signature.

B) Possible scenario for replay attack
A BAD actor could exploit a un-moderated opt-in mailing list in order to 
subscribe, send a spam to the list, receive its own spam signed by the 
listserver in order to replay it. This would affect the list server 
reputation but also the original sender reputation unless he's signature 
is removed or altered by the distribution processus.

A and B are true for any of 1/x/x (if the original message is modified 
or not and if the original signature is removed or not).

How can this signature be used by the final rcpt ?
What is it usefull for ? It can be used to prove that the message was 
relayed via the mailing list but usualy, when this is needed the list 
archives can prove it.
 
The list reputation can be used but to my mind, the original sender 
reputation seems to be the reputation that should be used.

Other cases are variant of 1/x/x and 0/x/x that cumul problems from both 
categories.

At the end, I can't identify the reason why a mailing should add a
signature to a message, may be because I didn't understand how third
party signature can be used with a signer (i=) different from the
message Sender. Also I can't see how MUA could deal with message with
multiple From: . It is definitively not a common usage and it will not
be accepted by users because it suppose some modification in MUA.
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: [email-masked] (Wietse Venema)
Date: Fri, 20 Jan 2006 09:06:18 -0500 (EST)

That's a good argument why the Lists's signature should not cover
the FROM:  etc. headers with the poster's address, but be limited
to the message headers that identify the List itself.

	Wietse

---

From: John Levine <[email-masked]>
Date: 20 Jan 2006 14:56:01 -0000

>lists to be at least a little picky about who they allow on.

Yes, exactly.

Hey, wait a minute -- isn't that what lists already do?

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Jan 2006 09:16:19 -0800

On Jan 19, 2006, at 8:44 PM, Eliot Lear wrote:
>
>> Most lists confirm the email-address by mailing back a link to  
>> verify that the participant indeed receives email at that email- 
>> address and wishes to subscribe to the list, a double op-in.  Will  
>> participants on a list need to have their own certificate?  You  
>> seem to be validating Phillip's concept of using trusted  
>> certificates rather than DKIM's self issued public keys.
>
> That's not really where I was going.  What I more envision is that  
> a mailing list will have its own reputation that will match the LCD  
> of the list, just as you say, but that the way to protect against  
> that is for lists to be at least a little picky about who they  
> allow on.

Perhaps the list-servers can be quick to kick-off bad-actors, which  
they are fairly good at doing, but what does being picky mean?  The  
bad actor would only need to send a message with a link, which is not  
something that would appear to be spam until it appeared in  
everyone's inbox.  When you say the reputation of the list, this too  
is rather problematic.  When the list is "thin" there may not be any  
DKIM signature added by the list-server.  Why would they want the  
grief so to speak?   If the list-server is "thick", then why pass on  
signatures that may have been damaged.  From a safety premise, no  
incoming signatures should be passed on as a best practice.

>   After all, we've said that dkim is just a part of the solution,  
> and we've indicated that reputation systems are important (albeit  
> out of scope for this group), so why not let them address this  
> problem as well?

There should be serious doubts about being able to keep up with a  
potential replay problem.  The dissemination of virus information is  
already a major expense, which makes extrapolating the budget needed  
for chasing "bad" signatures used in a replay both unpleasant, as  
well as likely too slow to be effective.  It would seem this is  
expecting too much of a reputation service.

> The ONLY time one removes a signature is when one breaks it.

The community already expects senders to be careful about where they  
send their messages.  If there is a common practice that all  
receiving domains keep incoming signatures from being seen and  
replaced by the MDA signature, the replay-abuse-list would not be to  
onerous to maintain.  That _could_ be a service that could be  
disseminated without taxing network bandwidth.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Fri, 20 Jan 2006 09:24:27 -0800

Good analysis.  A few comments embedded below.

Aumont - Comite Reseaux des Universites wrote:
>
> Lets try to identify the different possible cases when a signed
> message  is received  by the mailing list server. There are 3 actions
> that the mailing  list server can do :
>
>       The message is distributed with a valid signature. The original
> sender reputation will be used by final RCPT to evaluate the message :
> the mailing list server is transparent forwarder but final receipient
> can't use DKIM signature in order to prove that the  message was
> relayed by the list.
>
> If the sender SSP specifies  that all messages from this sender must
> be signed then this message is suspicious.
Case 0/0/1 should be included here as well, because invalid signatures
need to be considered exactly the same as missing signatures, neither
better nor worse.  See
http://www.mhonarc.org/archive/html/ietf-dkim/2006-01/msg00085.html for
the rationale for this.
> A) the mailing list server adds a signature i= (signer) and "From:"
> are different. The signature may be invalid if the sender SSP does not
> allow third party signature.
>
> A BAD actor could exploit a un-moderated opt-in mailing list in order
> to subscribe, send a spam to the list, receive its own spam signed by
> the listserver in order to replay it. This would affect the list
> server reputation but also the original sender reputation unless he's
> signature is removed or altered by the distribution processus.
We shouldn't make any assumptions about the way the reputation system
operates; remember that it could be a local, manually-maintained white
list as well.  Accreditation could be used here as well, especially by
larger list providers.
> relayed via the mailing list but usualy, when this is needed the list
Checking the archives works fine after the fact, but doesn't help in the
handling of the message.  If I want to treat certain messages
preferentially, perhaps because they come from the ietf-dkim mailing
list, I'd like to make that decision based on a signature.  Active
participants in a list are likely to treat the list preferentially, and
it's very easy to see who they are.  So an attacker might try to spoof
the list to get someone to read a message.
> Other cases are variant of 1/x/x and 0/x/x that cumul problems from
> both categories.
>
>
We should stay away from multiple From: addresses; MUA behavior is
inconsistent (we have done a few experiments).

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Jan 2006 09:35:59 -0800

On Jan 19, 2006, at 11:10 PM, Graham Murray wrote:

>> Those who are hoping what _may_ be visible to the recipient is  
>> being checked will not want conformance based upon any other  
>> header.  Of course, what is visible remains within the control of  
>> the sender,
>
> recipients mailer software. For example, with the mailer I use I  
> can (and have) configure it to show or hide whichever headers I  
> choose and can also (with a single button press) display all the  
> headers. I admit that not all mailer software makes it that easy,  
> but the mailer software used is under the control of the recipient  
> not the sender.

What is displayed is not really under the control of the recipient.   
The recipient may control which fields are displayed, such as the  
display-name or the display-name and the email-address, but the  
sender is still has a large number of tools at their disposal to  
control what is seen by the recipient in either case.  There are  
encoding methods defined by the native OS that are sometimes used,  
there is HTML encodings that may be recognized, there is RFC2047 that  
offers two methods of encoding where character-repertoires can even  
change.  What appears as normal syntax may not be seen as syntax by  
the email-application.  The sender can often pick characters of any  
language including ideograms, and glyphs.  There is also RFC3490,  
RFC3491, and RFC3492 that introduce the use of ACE labels within the  
domain name.  The email-application must then choose to display the  
ACE label or the characters selected by the ACE label.  A difficult  
choice where neither are really acceptable.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Jan 2006 09:54:29 -0800

On Jan 20, 2006, at 6:56 AM, John Levine wrote:

>> a mailing list will have its own reputation that will match the  
>> LCD of the list, just as you say, but that the way to protect  
>> against that is for lists to be at least a little picky about who  
>> they allow on.
>
> Yes, exactly.
>

The discussion was whether the DKIM signature itself can serve as a  
basis for acceptance.  In other words, can a DKIM signature safely  
accrue a reputation?  Unlike the client IP address currently used to  
assess list-servers,  the DKIM signature can be replayed and sent to  
recipients that were never intended by the list-server.  If the DKIM  
is to ever serve as a basis for acceptance, there must be a means to  
defend against the replay problem.  Don't assume this will be someone  
else's problem.

A best practice where all DKIM recipients immediately overlay  
incoming signature with a signature assigned the role of MDA by the  
MDA that would not be accepted by any other MDA would ensure messages  
available for replay could be contained.  There could be a new list  
created called dkim-abuse-list (DAL).  The sender could use this list  
to either disable signing when destine for a location known to have a  
replay problem, or simply not send the message.   This strategy  
should convince recipients to ensure the safety of the incoming  
signatures, or they could become listed.  Over time, the number of  
domains on the DAL should represent roughly the dynamics seen on  
other types of blocking-list.

-Doug

---

From: "John R Levine" <[email-masked]>
Date: 20 Jan 2006 13:18:39 -0500

> accrue a reputation?

If the answer isn't yes, I think we're wasting our time.

> A best practice where all DKIM recipients immediately overlay incoming
> signature with a signature assigned the role of MDA by the MDA that
> would not be accepted by any other MDA would ensure messages available
> for replay could be contained.

Even assuming that one thinks replay is a problem that DKIM needs to
address, which I don't, it's hard to imagine a rule like this being
implemented widely enough to be a problem for bad guys.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Jan 2006 11:22:20 -0800

On Jan 20, 2006, at 10:18 AM, John R Levine wrote:

>> The discussion was whether the DKIM signature itself can serve as  
>> a basis for acceptance.  In other words, can a DKIM signature  
>> safely accrue a reputation?
>

 From the recognition stand point, DKIM still offers value.  Without  
addressing the replay abuse issue, DKIM will not offer value with  
respect to acceptance.

>> incoming signature with a signature assigned the role of MDA by  
>> the MDA that would not be accepted by any other MDA would ensure  
>> messages available for replay could be contained.
>
> Even assuming that one thinks replay is a problem that DKIM needs  
> to address, which I don't, it's hard to imagine a rule like this  
> being implemented widely enough to be a problem for bad guys.

Any large domain today has a steady background of abuse taking  
advantage of the domain's size.  Other providers are reluctant to  
block messages from domains that represent millions of users, where  
the abuse is also often limited by rate restrictions.  When DKIM  
offers any acceptance value, this background abuse can and will be  
amplified by a replay strategy.  If the large domain can not control  
the background abuse, will they bother to do more to control a replay  
problem?

Defending the reputation of the signature creates a requirement that  
the senders find a way to control the replay abuse issue.  Several  
have suggested that this problem should be swept under the reputation  
services carpet and not be discussed. : (

There are tens of thousands of compromised systems sending out rate  
limited abuse within these large domains.  This abuse tends to be a  
mile wide and an inch deep, but represents in aggregate a substantial  
portion.  Disseminating domain/signature fingerprints for all of  
these potentially abusively replayed messages would unfortunately  
represent a substantial amount of data.  The bad actors can  
immediately amplify their abuse by many orders of magnitude.  The  
response needed to abate this activity will be encumbered by being a  
centralized aggregate of _all_ the replay abuse.  In other words, the  
bad actor will almost always win this race.

In the dkim-options draft, there were some solutions suggested to  
mitigate some of the overhead and to decentralize the revocation by  
having each sender publish their own abuse lists.  The SSP user level  
policy concept could be used to block access.  These will need short  
TTLs, and be queried frequently.  A broad distribution of user  
records ensures this resource requires inordinately large caches and  
high overhead.  There is the alternative of the revocation of the O- 
ID which does not return a record in most cases.  Either way, this  
will require that the sender expend administrative resources in an  
attempt to curtail a replay abuse problem.  Oh bother.

Initially, DKIM will offer value with respect to recognition and  
improved filtering of phishing attempts which does not require the  
SSP policy to be effective.  Over time, DKIM may offer valuable with  
respect to acceptance, but this will depend upon how well the replay  
abuse can be handled.  Establishing from the start a practice that  
ensures that a replay-able signature is never seen by a user would  
greatly assist in limiting the exposure.  If the recipient has not  
implemented DKIM, it may not make much sense from an acceptance  
standpoint to sign messages destine to these domains.  After all,  
signing takes some resources, so why use it when it may create a  
problem.  Perhaps initially, there could be a list created called  
DKIM-Adopters.  Unless the domain acknowledges that they protect  
incoming signatures and utilize DKIM for acceptance, they would not  
be added to this list.  Any replay abuse that occurs from messages  
sent to one of these domains could be grounds for removal.  Over  
time, the list may invert to represent only the abusers, depending  
which list represents the smaller population of names.

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 20 Jan 2006 22:06:03 +0100

[...]
> If I want to treat certain messages preferentially, perhaps
> because they come from the ietf-dkim mailing list, I'd like
> to make that decision based on a signature.

I think we're in trouble if the list signs something that is
already signed.  If you get a valid signature and the List-Id,
why do you want a second signature from the list in addition
to (or instead of) the "original" signature ?

> Active participants in a list are likely to treat the list
> preferentially, and it's very easy to see who they are.  So
> an attacker might try to spoof the list to get someone to
> read a message.

Yes, he'd get a throw-away domain. a PASS bound to it, and 
adds the List-Id to get around your guards.  OTOH he's an
unknown stranger from your POV, you wouldn't white list him.

So this trick won't work, let alone more than once for the
same throw-away domain.  But if this is somebody you know as
active participant you can white list him, and after that it
works for private mails from this participant as well as for
mails you get via the mailing list, and for courtesy copies.

                              Bye, Frank

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 20 Jan 2006 18:06:52 -0500

----- Original Message -----
From: "Aumont - Comite Reseaux des Universites" <[email-masked]>

> So we must examine benefits and problems for 8 cases:

This is good but there are 1 additional action, that "might" be separate
from the above, and this the subscription process. The LS must follow
SSP to restrict subscriptions from domains who have specific restrictive
policies.

> mailing list server is transparent forwarder but final receipient

First, I am approaching this from the standpoint of the existing SSP
draft specificaition and what it will take to deterministically follow
it so that it is 100% consistent with SSP and the SSP integrity is
maintained during the transport or routes and mail processing.

For this case, the LS can allow this for all policies, except:

  o=! EXCLUSIVE (signature required, no 3rd party allowed)
  o=. NEVER (no mail expected)

EXCLUSIVE does not allow for 3rd party or middle ware SENDER: address
domains.  However, if the LS is simply acting as a "passthru" system, no
change to control lines (headers) as well, then it might work here.

NEVER should have been handled by the the SMTP inbound verifier.

Correct.  In this case, a LS is not DKIM/SSP compliant.  It can not
operate in this mode if it makes any attempt to support DKIM/SSP.

> If the sender SSP specifies  that all messages from this sender
> must be signed then this message is suspicious.

Correct. I have no seen a definitive statement yet about stripping
(and/or replacement).  We need a statement about this.

Nonetheless, currently, from a consistency standpoint, the LS can not
stripped for the policies that require a signature, and/or a optional
policy but a signature is present if we declare that a signature message
can not be stripped.  If we allow it, the LS can only do a "Strip" for
the following policies:

  o=? WEAK (signature optional, no 3rd party allowed)
  o=~ NEUTRAL (signature optional, 3rd party allowed)

IMO, no stripping should occur unless it is replaced.

> A) the mailing list server adds a signature i= (signer) and
> "From:" are different. The signature may be invalid if the
> sender SSP does not allow third party signature.

Right, the LS can only add a signature for

  NONE (no policy)
  o=~ NEUTRAL (signature optional, 3rd party allowed)
  o=- STRONG (signature required, 3rd party allowed)

For this state, the LS can not add a signature for the remaining
policies

> A BAD actor could exploit a un-moderated opt-in mailing list in
> order to subscribe, send a spam to the list, receive its own
> spam signed by the listserver in order to replay it. This
> would affect the list server reputation but also the original
> sender reputation unless he's signature is removed or altered
> by the distribution processus.

The original spam is not from any DKIM secured domain.  How would this
harm other subscribers?  As long as LS follows the SSP, the spammer can
not exploit retrictive policies.  If the LS follows SSP, for this case,
it only allows case this to happen for NONE, NEUTRAL, STRONG which
allows 3rd party signing.

> or not and if the original signature is removed or not).

Well, it ain't going to work well if the LS blindly adds signatures. It,
as well as all mail reprocessors, must be consistent with the SSP
protocol to minimize all harm.

> reputation seems to be the reputation that should be used.

Sure. Thats obvious I think  but that is results declared by his relaxed
SSP.  If the domain uses a relaxed policies, then it asking for trouble.
This is already proved in practice with SMTP relaxed provisions where we
don't double check transaction entities and with SPF relaxed policies as
well, where its NEUTRAL policy is exploited and abused.   Same will
happen with DKIM/SSP relaxed provisions.  It should not expect any less
here.

> Other cases are variant of 1/x/x and 0/x/x that cumul problems
> from both categories.

Well, overall, its about following the SSP protocol.  Whether the SSP
protocol mandates too much strains or pressures for mail author to
change their wares, thats a different issue all together.   But if we
want it to work, well SSP defines exactly what sort of redesign projects
we have to do to support it. Otherwise it all for nothing.

> be accepted by users because it suppose some modification in MUA.

Right, the question of multiple FROMS for the MUA (offline or online) is
a non-issue.  Don't even go there.  Thats a fundamental change in the UI
ergonomics across the board.

But to me, this is all very simple.  SSP is a very strong protocol, like
Dave Crocker mentioned "Its scary."

This is all about "how much" we want to change our software to support
the SSP protocol.   SSP to me is about "double checking" domain
declarations.  We don't have anything today that offers this level of
verification in the SMTP/EMAIL transaction process.  We have strong SPF
policies and that is the closest thing to have. But it has its mail
forwarding issues and DKIM resolved this specify issue. This is the
MISSING piece.  If did not, DKIM would not be needed. SPF is sufficient.
But if compliant systems play the DKIM/SSP role correctly,  then in my
opinion, we got a winner. It will work 100% for restrictive policies
from high-value domains who want it, it work less than 100% for relaxed
domain policies. But like all things relaxed, these policies and
provisions will always be exploited.

So how much we want to change our software is the bottom line here.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: Douglas Otis <[email-masked]>
Date: Fri, 20 Jan 2006 16:28:15 -0800

On Jan 20, 2006, at 1:06 PM, Frank Ellermann wrote:

>> because they come from the ietf-dkim mailing list, I'd like to  
>> make that decision based on a signature.
>
> already signed.  If you get a valid signature and the List-Id, why  
> do you want a second signature from the list in addition to (or  
> instead of) the "original" signature ?

Trusting the list-server's diligence in controlling abuse, the  
signature of the list-server would have greater value and this  
prevents simple spoofs.

Accepting the possibility that a cryptographic signature allows  
replay abuse, this may lead to a paradigm of protecting signatures to  
preserve their acceptance value.  As such, a list-server should also  
obfuscate the original signature with say 'b=!Verified'.  Obfuscation  
would eliminate a replication of effort and should be included within  
the list-server signature.  This allows messages to be modified as  
normal.  Obfuscation would also ensure the list-server prevents any  
replay abuse of one of the participants.

The list-server could also include a RCPT TO: hash within the  
signature to provide each recipient a means to delay acceptance when  
a message may be a replay.  The RCPT TO: hash would also ensure each  
recipient obtains a unique message for replay abuse tracking.  Closed  
policies still interfere with the use of a "thick" mediator.  A  
"thin" mediator however means tracking abusive destinations will be  
impractical.  For DKIM to have any value for acceptance, abusive  
replay must be overcome.  Protecting the signature offers the lowest  
administrative overhead for achieving that goal.

>> preferentially, and it's very easy to see who they are.  So an  
>> attacker might try to spoof the list to get someone to read a  
>> message.
>
> Yes, he'd get a throw-away domain. a PASS bound to it, and adds the  
> List-Id to get around your guards.  OTOH he's an unknown stranger  
> from your POV, you wouldn't white list him.

All participants would need to be white-listed individually?

Indeed, the throw-away domain would be just that, a throw-away  
perhaps purchased months ago as their cost of advertising.  Even a  
"picky" list-server would be unable to overcome this strategy.  A  
stealthy list-server participant could post rather innocent looking  
messages containing links to topic relevant web-pages.  These  
messages may then appear later in everyone's inbox, where the web- 
pages are now browser exploits, for example. :-(

The reputation protection strategy could be to not sign messages  
destine for where replay abuse may occur as indicated by community  
lists.  This would instill a best practice that obfuscates incoming  
signatures which then replaces these signatures, especially at the MDA.

With this paradigm, had the list-server not taken ownership by  
signing the messages and obfuscating the incoming signatures, they  
may appear on a DKIM-Abuse-List or perhaps removed from a DKIM- 
Adopters list.  When the list-server discovers their signature is  
being abused by a replay, they would then know which destination to  
report.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Sat, 21 Jan 2006 02:41:46 +0000

> to (or instead of) the "original" signature ?

Because a signed List-ID proves it came via the List that I've
subscribed to. An unadorned List-ID could, shall we say, be forged.

Since I am likely to know the list I can filter appropriately but I am
unlikely to know the original signer and would not want to filter on
that.

Even if such distinctions are not well made today, we should enable
the possibility rather than preclude it and then have to deal with it
in five years time with another DKIM-like WG.

Mark.

---

From: John Levine <[email-masked]>
Date: 21 Jan 2006 02:44:06 -0000

>to the message headers that identify the List itself.

Seems to me that it tells us that list software shouldn't forward
messages from domains that use SSP to say no third party signatures.

There are all sorts of techniques that people use to validate mail
sent to mailing lists, from passwords in the message to challenges
back to the sender to manual moderators who know the writing styles of
their contributors.  If the sender's been validated, why shouldn't the
list software sign the while message?

Thinking about the situations where domains would be likely to use SSP
to say no third-party signatures, it's hard to imagine one where they'd
want their mail to be forwarded through a mailing list.  If mail through
a list fails with that SSP setting, it's probably a feature.

This scenario also may be a hint that the current model of SSP won't
be very useful, but I don't think we'll know until we try it.

R's,
John

---

From: Mark Delany <[email-masked]>
Date: Sat, 21 Jan 2006 03:17:38 +0000

>  o DKIM sign the content so as to include List-ID

Oh, the point I forgot to mention here is that with this guidance, in
many[1] cases simple List software does not need to make *any* change
to participate.

All that needs to happen is that the out-going mail system - that has
to be changed to sign anyway - recognizes the presence of List-ID and
sign for the mail accordingly.

Mark.

[1] BY many cases I mean the simple List s/w that relies on a regular
MTA to do the delivery, I understand that a good amount of specialized
List s/w manages deliveries directly and they indeed would have to
change.
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 21 Jan 2006 14:12:35 +0100

Mark Delany wrote:

>> already signed.
[...]
> a signed List-ID proves it came via the List that I've

So far it was my impression that DKIM tries to establish some
accountability as near to the "originator" as possible.  As a
simple rule that's "if it already has a valid signature, don't
touch it".

If you try to decompose this into more MON -> *mediator -> MRN
pieces what you get is SPF.  Apparently you and Jim think that
lists are reliable filters, catching all kinds of bad actors.

IMHO they are not, they can screw up like everybody else.  And
many of them are FUBAR adding bogus subject tags, adding bogus
footers to text/plain, adding controversial PRA header fields,
and adding bogus Reply-To list header fields.

Some go so far as to force their footer into any content type
that's not text/plain by manufacturing a multipart/mixed with
their funny footer in an additional text/plain part.

Any decent mail2news gateway like GMaNe undoes some of these
dubious list manipulations, it removes the bogus subject tags
and the weird text/plain footers.  I'd love it if GMaNe would 
also strip all Reply-To list, I'm used to Re:news -> to list,
Re:Mail -> to author, Re:both -> guess, but I digress.

In that muddy waters DKIM should try to stay out of trouble and
make it as simple as possible at least for those lists wishing
to do "the right thing".  Whatever that might be, certainly not
adding funny footers, subject tags, and Reply-To list.

"Got valid signature -> don't touch it" is a simple rule.  It's
as near to "end-to-end" as possible with DKIM.  For something
that's radically NOT "end-to-end" folks know where to find SPF
(with zero impact on mailing lists).

If DKIM-aware lists would be forced to do different things for
submitters depending on their SSP of the day it's messy.

If an existing signature is valid that should be all the list
needs to know:  No lookup of the SSP trying to determine what
it says today about third party signatures.

> Even if such distinctions are not well made today, we should
> enable the possibility rather than preclude it and then have
> to deal with it in five years time with another DKIM-like WG.

Well, I can't nail it, but my gut feeling is that it's wrong.

Fortunately there's no such thing as "sign some - third party
never" in SSP, so at least for unsigned mails the situation is
clear for DKIM-aware lists.
                           Bye, Frank

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 21 Jan 2006 10:00:07 -0500

From: "Frank Ellermann" <[email-masked]>

> simple rule that's "if it already has a valid signature, don't

As an author of a list server, I prefer to STRIP the signature when
allowed to avoid tampering with the many options already offered to the
list owner.

>From the point of view of the message author, the signed message sent to
the list agent has already reached it final destination and has
accomplished its goal of a secured transaction.  At this point, the list
owner takes over.

What that means that in order to be consistent with the SSP protocol, it
should only be abled to do this for:

         NONE (no policy)
    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd party allowed)

The LS server will:

 NONE,    do not sign message
 WEAK,    strip, do not sign
 NEUTRAL, if any strip/replace if he wants to resign it.

This is the only way the protocol integrity will be maintained when the
submitted message is expanded and distributed to downlink DKIM
receivers.

> clear for DKIM-aware lists.

What about the WEAK (o=?) policy?

I am operating under the assumption that people's input, including Arvel
Hathcock who suggested the WEAK policy are taken seriously and will be
added the updated DRAFT SSP.

---

From: Frank Ellermann <[email-masked]>
Date: Sat, 21 Jan 2006 18:09:29 +0100

Hector Santos wrote:

> As an author of a list server, I prefer to STRIP the
> signature when allowed to avoid tampering with the many
> options already offered to the list owner.

If you tamper with the message that's your best choice.  But
ordinary lists don't tamper with messages, they redistribute
them as is, adding their List header fields, and using their
own Return-Path for automatical handling of errors.

Sympa also adds an Errors-To reflecting the Return-Path, and
that's the main case where DKIM must work transparently, for
unmodified redistributed mails.

Strip old signature or similar recipes are hardcore gateways
stuff, not be part of normal DKIM procedures.  Gateway operators
are supposed to know what they do.

>     o=?  WEAK (signature optional, no third party)

Oops, there it is, when I checked the SSP draft some hours ago
I missed this.  What does WEAK mean for an _unsigned_ mail at
a third party willing to sign it ?  I hope it means nothing in
this case and affects only signed mails.

>  WEAK,    strip, do not sign

Stripping a valid signature makes no sense for redistributors.

That's only necessary if the original mail is mutilated beyond
recognition, the forged / broken / inconvenient (pick what you
like) cases.

DKIM can't do much about these cases, recommend to exclude the
subjects from the signed header fields maybe.  If the bad guys
try to abuse this by squeezing their spam into the subject let
them, it won't work as expected.

> What about the WEAK (o=?) policy?

Yes, no part of the actual SSP draft.  Not yet or not more ?

I don't see how it could work for unsigned mails.  Should third
parties willing to sign mails always check the SSP ?  In that
case I'd say a simple implementation of third party signatures
is DON'T.  Fast, robust, and no chance to get in trouble.  Bye

---

From: Dave Crocker <[email-masked]>
Date: Sat, 21 Jan 2006 09:23:14 -0800

J>> At the end, I can't identify the reason why a mailing should add a
> inconsistent (we have done a few experiments).

Jim,

What do you mean "stay away from"?  Multiple From addresses are legal and gets 
used occasionally, with existing MUAs.

Unless DKIM is going to attempt to change RFC2822 rules, we cannot have DKIM 
fail to handle a legal header case.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Jim Fenton <[email-masked]>
Date: Sat, 21 Jan 2006 10:29:41 -0800

Dave Crocker wrote:
> What do you mean "stay away from"?  Multiple From addresses are legal
> and gets used occasionally, with existing MUAs.
>
> Unless DKIM is going to attempt to change RFC2822 rules, we cannot
> have DKIM fail to handle a legal header case.
Agreed; what I said wasn't very clear.  What I meant was that we should
avoid additional usage of multiple From fields as part of DKIM.  For
example, one way of making the signer address visible might be to put it
in the From field as an additional author, e.g.:

From: "Jim Fenton" <[email-masked]>, "Signed by ietf-dkim"
<[email-masked]>

I'm not sure anyone is proposing that, but it could otherwise be seen as
logical since some of the content came from me, and some (the message
trailer, for example) came from the list manager.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Sat, 21 Jan 2006 11:09:30 -0800

> <[email-masked]>

oh.  right.  i entirely agree.  as i've commented many times, i think the DKIM 
specification should stay away from human factors issues, such as signaling 
signatures via the From field.

d/
-- 

Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 21 Jan 2006 20:41:55 -0500

> own Return-Path for automatical handling of errors.

Just to be clear, I was referring with screwing around with all the
existing options that a sysop traditionally desires in mailing list
based distributions.

Right, we have the "thin, slim and fat" models.  Again, these are all
list sysops preferences.

> unmodified redistributed mails.

We are talking body content mostly, not the headers, or network control
lines. Our LS also adds Error-To.   No doubt, we desperately need a new
WG for LIST SERVERS. There are many old issues that needs to get
resolved.  Everyone is designing and operating on a BCP mode and mostly
based on the original LISTSERV <tm> product.

> are supposed to know what they do.

Well, a LS can be viewed as a GATEWAY, a gate from a 1 to 1 Email
Protocol to a 1 to Many "Groupware" system.  That's part of the design
conflictive issues we deal with all the time.  Sure, GATES usually deal
with heterogeneous networks or formats, but for all intent and purposes,
the way we use List servers today is basically KLUDGING email to be a
"Groupware" conference systems.

The ultimate question is, who "owns" or has control of the message. Once
the message is submitted to a list or MDA (final destination) for the
matter, many will argue, including myself, the LIST server does as a
gate.  The message author has accomplished its goal of submitting a
message to an (list) address.  That part is completed.  After that, he
has no control of what happens and for the most part, NO say about the
storage, transformation presentation and/or distribution.

[Side Bar: Traditionally, based on US ECPA precedence already
established the storage owner does the email property. However,
traditionally not for passthrus (including an ISP hosting sending USER
outbound mail) That is one reason why "thou shall not tamper with
passthrus" exist .  But there is a appeals case right now that is
challenging this in regards to SNIFFING passthru mail to spy on
competitor content information.  The STORAGE ownership status (temporary
as a passthru) prevailed in the original case. This is being currently
appealed.  It will probably reach the supreme court, as it should.]

All in all, there is only two things you have to worry (to be safe)
about when it comes to possible US ECPA conflicts:

    - don't change the meaning of the message
    - don't censor it.

But the US Congress already relaxed this too in 2000 to address the
Mommy market (Kiddy Porn) and to encourage the Mail Filtering Technology
market.  This tort-reform protection is for PUBLISHERS of information,
not PROVIDERS.  But the law specifically includes  "Good Samaritan"
provisions which basically says "don't go crazy with this power."

Note much to the chagrin of Levine,  this has nothing to do with
"Playing Lawyer" but rather understanding the laws and basic engineering
ethics as it applies to your business and product lines.

> a third party willing to sign it ?

To me, if is SSP is suppose to define what a DKIM/SSP compliant mail
processor is suppose to do, it means it can't sign it.

> Stripping a valid signature makes no sense for redistributors.

Well, to maintain the transport consistency, it does. Whether it implies
some other possible "no-no", that's a different either.   As of today,
we are not in the business of stripping stuff.  Well, I take that back.
It exist and I predict it will get worst, in the area of Ad-Ware email.
Some receivers are already stripping this junk.  Vendors that have been
doing this have been swamp with tortious interference lawsuits and if
they keep it up, smarter receivers, especially MUA will simply filter
this non-original added junk out.

> recognition, the forged / broken / inconvenient (pick what you

Probably.

Frank, if you just look at what SSP is (right or wrong), what it means,
you can sit down and design the interface specs for your mail
processors.

If the final issue is "Well, its too much of a change for everyone to
realistically do", well, that's a different issue.

So far, it really isn't that bad IMO.

Ultimately, it will be the DKIM owner that is going to define what
happens.  If he is blindly uses his new "marked" DKIM domain in public,
well, at some point, he will have trouble.

Exploiters will simply look for receivers that do not support DKIM and
blast away at this sites with both non-signed and signed, forged or
otherwise signatures.   That isn't going to change until DKIM is widely
adopted, and even then, they will continue to look for non-DKIM sites,
just like the original CODE-RED virus continued to look for unpatched
IIS machines until eventually it was negligible.  It took atleast 3-4
years before it became insignificant.

If anything, it is the realization by hackers that tells them it is
"worth" trying out a hack because there will always be enough of a
legacy market to exploit.

So to me, we need to go strong with DKIM/SSP and be very careful about
the relaxation of the protocol.  Either you support it or your don't.
No in-between.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 21 Jan 2006 19:48:06 -0800

> the relaxation of the protocol.  Either you support it or your don't.

Do you mean only closed policies should be published with DKIM?

Do you mean some policy should be published?

What benefit for the sender is there publishing a default open-ended
policy?

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 22 Jan 2006 09:45:22 +0100

Hector Santos wrote:

> Just to be clear, I was referring with screwing around with
> all the existing options that a sysop traditionally desires
> in mailing list based distributions.

<joke mode="fido"> My desire to screw around with echomail
 was somewhat limited to the "reduced seen-by lines" </joke>

Traditionally sysops don't want to screw with in-transit mail,
in their religion that's a taboo.  Anybody with the desire to
get in serious trouble can still start a gateway or cancelbot.

The survivors can quote chapter and verse of obscure texts
like son-of-1036 by heart.  It's clear that you're one of them,
but I doubt that there are much more than a hundred worldwide.

> No doubt, we desperately need a new WG for LIST SERVERS.
> There are many old issues that needs to get resolved.

Makes sense.  Maybe when USEFOR and 2821bis are ready would
be a good time.  That's unfortunately too late for DKIM.

> the way we use List servers today is basically KLUDGING
> email to be a "Groupware" conference systems.

Groupware is a big word, it can cover everything from vCard
and calendar formats up to XMPP / Atom / Wiki / subversion
and what else.  Mailing lists probably have their place in
this broad concept, but this won't require them to add funny
trailers or subject tags to ordinary mails (excl. digests).

Quite the contrary they'd be expected to do nothing that can
destroy S/MIME / PGP / vCard.  Or back on topic now DKIM.

Ignoring PRA one case to watch for DKIM is "Reply-To: list".
If participants want this they should be free to get it from
their list.  So that's tricky if the original sender already
set a Reply-To, or worse if a signing entity before the list
signed that there is no Reply-To.

 [author to list arrived at list server]
> After that, he has no control of what happens and for the
> most part, NO say about the storage, transformation
> presentation and/or distribution.

Arguable, but I'm not rejecting it as valid model, I'm only
concerned how deep DKIM wants to get involved with the fine
print of this model,  So far I'd say that anything where PGP
or S/MIME would fail miserably is also out of scope for DKIM.

With the option to arrange things to work with trivial cases,
taking John's ASRG experiment as further input, and maybe
some known mail2news + news2mail idiosyncrasies.

> one reason why "thou shall not tamper with passthrus" exist

Let's ignore legal aspects and US law, as John said we're no
experts for such issues.  AFAIK any tampering without prior
consent of all involved parties could be also relevant for an
article in the German "base law" (an ersatz-constitution).

For a mailing list the author and all recipients subscribed,
that should be good enough for the legal side of things.  Or
maybe not for cases of PRA != author, but IIRC Jim said that
he will fix most "originator" to "authors" in his draft.

>> What does WEAK mean for an _unsigned_ mail at a third party
>> willing to sign it ?

> To me, if is SSP is suppose to define what a DKIM/SSP
> compliant mail processor is suppose to do, it means it can't
> sign it.

Okay, then Jim's very first diagram in the threats draft _is_
wrong, it suggests to look at the SSP only for signed mails.

Now you propose a procedure where you have to look at the SSP
also before signing anything.  We need a diagram covering the
MON -> mediator -> MRN case.  One mediator as a placeholder
for zero or more mediators.  (Read "sysop" if you don't like
"mediator", in that case I don't care about the terminology.)

> I predict it will get worst, in the area of Ad-Ware email.
> Some receivers are already stripping this junk.

Yes, that's convincing.  OTOH I'm not interested in a design
where DKIM-signed mails with ESP-Ads survive mailing lists
adding their own Ad-trailers or similar stunts.  Bye, Frank

---

From: Miles libbey <[email-masked]>
Date: Mon, 23 Jan 2006 12:14:37 -0800

> (with zero impact on mailing lists).

This is very interesting. For our antispam system I'd like to be able
to distinguish between mailing list traffic and person to person
traffic, since they largely have very different characteristics.  In
this sense, to me, 'do the right thing' would be to re-sign the
message -- we've been able to use Yahoo! Groups (re)signing as a
feature.  I'm sure that others could easily argue that doing the right
thing is to leave the message in a way that encourage the final
receiving system to check the initial signature, so they could apply
rules based on the original author.

miles

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jan 2006 12:30:20 -0800

> rules based on the original author.

Hmmm.

Sounds like good reasons for two, different styles of signature use.

Sounds like a good reason to permit both and let operators and users, in the 
wild, play with them and find out what scenarios are the most helpful.

Therefore it seems that,

    a) we should not specify DKIM in a way that makes either scenario 
automatically break -- where "automatically" means that a user of DKIM might, on 
their own, do something to break one or another scenario --  and

    b) we should not recommend or require either scenario, although 
non-normative discussion could provide helpful pedagogy, to show DKIM's possible 
flexibility.

d/
-- 

Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Jan 2006 13:09:41 -0800

On Jan 23, 2006, at 12:14 PM, Miles libbey wrote:

> This is very interesting. For our antispam system I'd like to be  
> able to distinguish between mailing list traffic and person to  
> person traffic, since they largely have very different  
> characteristics.

It is possible direct person to person traffic and list-server  
traffic use the same signing domain.   The proposal for the 'w=?'  
parameter is to identity three roles.  The MSA, mediator, and MDA.  
The MDA is intended to provide a non-deliverable signature, used in  
much the same way as a non-routable IP address for local networks.   
When the signature includes a meditator designation, rules regarding  
the use of headers can be so tailored.

> In this sense, to me, 'do the right thing' would be to re-sign the  
> feature.

Agreed, but the domain itself may not be a clear indication that the  
role of the MTA is a mediator and there are more mediators than just  
list-servers.  This would be more important when DKIM is attempting  
to identify the source of originating email (MSA), and ensure it is  
not confused with mediators such as list-servers, where it could be  
seen otherwise as a spoof attempt.

>  I'm sure that others could easily argue that doing the right thing  
> is to leave the message in a way that encourage the final receiving  
> system to check the initial signature, so they could apply rules  
> based on the original author.

The concern there would be whether an anti-replay strategy develops  
that attempts to hold the receiving domain accountable for replay.  I  
can not imagine how one could use DKIM  to safely hold the email- 
address accountable.  The replay abuse could just as easily occur  
from the recipient.  As a general rule, accountability should be  
focused on the domain as a practical and manageable level of  
resolution.  There is virtually zero cost associated with adding  
additional email-addresses, so what would a email-address reputation  
be worth?

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jan 2006 21:41:05 +0000

>> rules based on the original author.

Indeed.

> Sounds like good reasons for two, different styles of signature use.

Ok, just for the moment, let's assume that we did that.

I guess the obvious next question then would be: why only two? That
is, are there other use cases which are sufficiently different that
some level of extensibility is needed?

This could represent a potential slippery slope, but if we added
some kind of signature typing, with each type having associated
rules, we could define two types now, (perhaps originating MTA
and list server) and then someone else could define others later
on.

But is there a need for that?

> Sounds like a good reason to permit both and let operators and users, in 
> the wild, play with them and find out what scenarios are the most helpful.
> 
> Therefore it seems that,
> 
> automatically break -- where "automatically" means that a user of DKIM 
> might, on their own, do something to break one or another scenario --  and
> 
> non-normative discussion could provide helpful pedagogy, to show DKIM's 
> possible flexibility.

Nice summary,
S.

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 23 Jan 2006 22:51:09 +0100

Douglas Otis wrote:

> The proposal for the 'w=?' parameter is to identity three
> roles.  The MSA, mediator, and MDA.

An MSA probably knows what it is, also if it delegates the
signing to an additional "mailout" MTA.  I'm not sure about
mediator vs. MDA, do they always know what they are ?  Is
that an important difference in your SSP-alternative ?

And do you really mean MDA, not maybe MRN ?  If DKIM-aware
MRNs wish to reject mails based on DKIM-checks they can't
check at the MDA, they've to do it at their border (= MXs).

> The MDA is intended to provide a non-deliverable signature

Shaky.  I understand only very small pieces of your w-model,
if at all, but IIRC that part was about protection against
replay attacks abusing the signature of the sender.

In other words the sender has to trust that the receiver
gets this protection at his MDA (or before it) right.

> there are more mediators than just list-servers.

Good, bad, and ugly (the latter for "canonicalization")
list servers, the "bad" cases also cover gateways.  Then
forwarders, for DKIM they are all good, more or less the
opposite situation as with SPF, where lists are all good.

What other mediators do you have in mind ?  The moderator
of an article submitted to more than one moderated group
could be a special case, and at the moment I can't say how
that works.  But in essence they only add "Approved" until
either all moderators approved it, and the last injects it
into NetNews, or one of them rejects it.

Caught in my outbound:  Of course, forwarders supporting
PRA try their magic with Sender or Resent-* header fields.
That could be also "bad".  Why am I not surprised, sigh...

                           Bye, Frank

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Jan 2006 15:35:50 -0800

> some level of extensibility is needed?

hadn't been thinking of a restriction in number.  the general model seems to be:

Permit multiple signatures that do not (necessarily) conflict.

Personally, I'm extremely worried that this will create mayhem, but there have 
been simple, reasonable -- and maybe even compelling -- usage examples that 
would be wrong to prevent.

So my own view is simplicity and expediency means that we should not go through 
the design of the different scenarios, but flexibility and power mean that we 
also should not do anything knowingly to prevent experimenting with them.

> This could represent a potential slippery slope,

yup.

  but if we added
> and list server) and then someone else could define others later

signature "typing"?

I suggest, instead, that we make sure the signature header remains extensible 
and that any future decision that we need to adding parameters, such as a type 
field, be pursued then.  Later.

d/

-- 

Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Jan 2006 17:36:22 -0800

On Jan 23, 2006, at 1:51 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
>> The proposal for the 'w=?' parameter is to identity three roles.   
>> The MSA, mediator, and MDA.
>
> An MSA probably knows what it is, also if it delegates the signing  
> to an additional "mailout" MTA.  I'm not sure about mediator vs.  
> MDA, do they always know what they are ?  Is that an important  
> difference in your SSP-alternative ?

Just as the 's=' and 'i=' need to be established, consistent with  
various rules, so would the 'w=' as a means to indicate both what  
role the signature represents, but also what elements within the  
message have been verified.

> And do you really mean MDA, not maybe MRN ?

The MDA signature role could encompasses any receiving MTA within the  
receiving AdmD.  I am not sure if that is the same as the MRN.

> If DKIM-aware MRNs wish to reject mails based on DKIM-checks they  
> can't check at the MDA, they've to do it at their border (= MXs).

Exactly.  The term MDA signature could read "a signature only  
suitable for the MDA".  The MDA signature provides a secure means to  
both overlay incoming signatures with a verification result and yet  
ensure the message is not spoofed by an injection into the receiving  
AdmD.  The MDA signature could not be used to stage a replay attack,  
as only an MDA within the domain of the MDA signature would accept  
the message.  Any abuse in that case would be within the control of  
the receiving AdmD and should not impact the reputation of the  
sending MTA.

> Shaky.  I understand only very small pieces of your w-model, if at  
> all, but IIRC that part was about protection against replay attacks  
> abusing the signature of the sender.

The MDA signature would be an optional method to protect messages,  
when incoming signatures are overlaid with the result of the  
verification.  The overlay protects against any recipient within the  
receiving domain from using the message to stage a replay attack.   
This keeps the receiving domain off the DKIM-Abuse-list.  Adding the  
MDA signature at the edge of the AdmD where the overlay should occur,  
protects the message as it travels to the MDA.

> In other words the sender has to trust that the receiver gets this  
> protection at his MDA (or before it) right.

When the sender finds that their messages are being replayed (perhaps  
a bad actor has gained access within the sending domain), when the  
receiving domain fails to protect the signature from this type of  
abuse, the sender may choose not to sign messages for that  
destination, or perhaps someday not send messages to that  
destination.  The signature overlay strategy allows holding the  
domain accountable, rather than dispersing accountability to each  
email-address when signatures are not overlaid.  Such dispersion of  
accountability at the email-address would create an impossible  
situation to manage.

> Good, bad, and ugly (the latter for "canonicalization") list  
> servers, the "bad" cases also cover gateways.  Then forwarders, for  
> DKIM they are all good, more or less the opposite situation as with  
> SPF, where lists are all good.
>
> What other mediators do you have in mind ?  The moderator of an  
> article submitted to more than one moderated group could be a  
> special case, and at the moment I can't say how that works.  But in  
> essence they only add "Approved" until either all moderators  
> approved it, and the last injects it into NetNews, or one of them  
> rejects it.

A mediator would be those MTAs offering a service where the message  
is not directly from the author identified by the From.  Such  
messages are subjected to modifications or the inclusion of  
modifications or content beyond the direct control of the author,  
while still using the same From header.  This could include gateways,  
but may include other types of services.  In the case where incoming  
messages routinely have their signatures overlaid, even simple  
forwarding where only the RCPT TO: header is being changed should  
fall within this category.  Depending upon the level of  
implementation of the forwarding agent, the signature may retain the  
role of MSA, or be altered to accurately indicate the role of the  
mediator.  This uncertainty of roles should not cause any problems  
for the recipient, as they specifically establish this arrangement.   
It would be helpful to retain original signature headers where only  
the 'b=' parameter is overlaid with the verification results.   
Stripping these signature headers could inadvertently remove valuable  
information.  When resending these messages by an mediator, the most  
recent MSA header should be retained as overlaid.  Any sending of a  
message should remove the MDA signatures.  When sending, an MSA  
should remove any mediator signatures.  When receiving, the MDA  
signature should retain the most recent mediator and MSA signatures  
as overlaid.

> Caught in my outbound:  Of course, forwarders supporting PRA try  
> their magic with Sender or Resent-* header fields. That could be  
> also "bad".  Why am I not surprised, sigh...

That too would be an example of a mediator.  Assume that the  
recipient uses source identifiers (which may be the From address:MSA  
signature) to recognize and highlight a previous correspondent.   
Assume that messages from list-servers (From address:mediator  
signature) should not raise a conflict, but rather are treated as a  
difference class of message sources.  Each role can be highlighted  
differently and registered separately, or simply ignored as less  
important.  I'll refrain from creating a table of happy faces with  
different color schemes.  : )

-Doug

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 25 Jan 2006 17:15:16 +0100

> The MDA signature role could encompasses any receiving MTA
> within the receiving AdmD.  I am not sure if that is the
> same as the MRN.

I mentioned MRN because checking is better done at the border
in the case of a reject, and with out-sourced MXs the MXs do
not belong to the same "AU" as the MDA (different admins).

If Dave's new term "AdmD" somehow covers everything from MX
to MDA no matter how it's organized we probably mean the same
thing.  In one diagram "AdmD" it was apparently the same as
"AU", only a new acronym defined elsewhere.  Of course there's
a good chance that I never understood his "AU" term correctly.

                           Bye, Frank