Subject: [ietf-dkim] New issue: DKIM and mailiing lists

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Mar 2006 17:37:29 +0000

We had a long thread about this that I summarised, thus kicking
off an even longer thread (don't do it again, please - say what
you think about the threats doc instead!)

Serge Aumont, who's involved in some Internet2 work sent me a
link [1] to a wiki page where he tried to further summarise.

This issue is really just to get the topic on the Dallas agenda,
though I'm not sure I expect it to be fully resolved there.

Stephen.

[1] http://www.sympa.org/wiki/doku.php?id=dkim_and_mailing_lists

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Mar 2006 14:15:56 -0800

> though I'm not sure I expect it to be fully resolved there.

There is enough history, talking about mailing lists and signatures, over the 
last few years, to know that it can be a wonderful time sink.

So if this is going to be on the agenda, I suggest that it be specific questions 
or problems, with specific suggestions for specific resolutions.

Otherwise we will simply wander among the weeds of this topic's complexities.

d/

-- 

Dave Crocker
Brandenburg InternetWorking
<http://bbiw.net>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Tue, 14 Mar 2006 14:29:19 -0800

Dave Crocker wrote:
> There is enough history, talking about mailing lists and signatures, 
> over the last few years, to know that it can be a wonderful time sink.
> 
> So if this is going to be on the agenda, I suggest that it be specific 
> questions or problems, with specific suggestions for specific resolutions.
> 

And at this point, I really think what we need is data far more
than we need conjecture. I'm in the beginning process of getting
more data on this subject in our deployment, but don't yet have
any meaningful numbers. Hopefully within the next few months though.

		Mike

---

From: Barry Leiba <[email-masked]>
Date: Tue, 14 Mar 2006 20:56:13 -0500

Dave says...
>> questions or problems, with specific suggestions for specific 

Agreed... see below.

Mike says...
> any meaningful numbers. Hopefully within the next few months though.

That sounds good.  I think some good data will be a good starting point, 
and I appreciate that Mike's working on providing some.  Thanks.

As I interpret the discussion that we've had with Russ, and the 
requirement for mailing-list consideration that was added to the charter 
as a result of concerns from the Vancouver BOF, I believe that an 
analysis of the mailing-list issues is a prerequisite to having the base 
spec approved as an RFC (that is, it's not something we can do later).

I suggest -- and I haven't discussed this with Stephen, so, Stephen, 
pipe up if you disagree -- that we get a small group (up to three, I 
think) of participants who are concerned about this and who have 
appropriate experience, and work up an Internet Draft discussing the 
mailing-list issues.  That draft would either be merged with the base 
spec before the latter goes to the IESG, or would be sent at the same 
time, as a companion document.

Thoughts?

Barry

--
Barry Leiba, Pervasive Computing Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Mar 2006 18:30:14 -0800

> appropriate experience, and work up an Internet Draft discussing the 

Folks,

Let me suggest a variation on this theme:

1.  Anyone who has concerns should express them to the list, succinctly and 
concretely.

2.  Anyone who believes there are (or should be) no concerns should express them 
to the list, succinctly and concretely.

3. #1 and #2 should include soliciting comments from various security folks and ADs.

4. Your select design team can formulate their own list and integrate it with 
that produced through #1-3.

My concern is that what you have suggested, on its own, a) has no outside 
direction and is therefore an entirely open-ended task, and b) provides us with 
no basis for knowing whether the work will be responsive to the concerns others 
-- potential critics -- might hit us with later.  Rather than playing a guessing 
game, we should require statements now.

Then, the design team effort is to formulate responses, rather than formulate 
questions.

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Mar 2006 18:37:19 -0800

Taking my own advice:

Mailing list software takes delivery of a message and posts a new message.  The 
new message might look almost exactly like the old one or it might look 
massively different.

> 1.  Anyone who has concerns should express them to the list, succinctly 
> and concretely.

If a signature includes a useful hash of the message, it cannot survive really 
extreme violence.  Hence, a signature cannot reasonably survive transit through 
a mailing list that makes major changes to the message.

DKIM cannot survive transit through some mailing lists and it is not reasonable 
to make it try.

> 2.  Anyone who believes there are (or should be) no concerns should 
> express them to the list, succinctly and concretely.

Some lists merely add headers.  Some lists merely add text to the body.  These 
are quite common behaviors and they both are quite structured.

DKIM's body length counting mechanism and selective inclusion of headers in the 
signature hash are robust against such changes.

Some mailing lists can modify some of the body data encoding.  DKIM's 
canonicalization choices provide a reasonable degree of robustness against such 
changes.

d/

-- 

Dave Crocker

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 14 Mar 2006 19:55:41 -0800 (PST)

On Tue, 14 Mar 2006, Dave Crocker wrote:

> Taking my own advice:
>
> Mailing list software takes delivery of a message and posts a new message. 
> The new message might look almost exactly like the old one or it might look 
> massively different.

Massively different is overstatement of how mail lists work. For almost
all mail lists the message would have the same message text body with 
potentially small additional mail-list footer and potentially change in
a subject and several new mail-list identification header fields and
what is important is that it will retain the same author info (from
field) and same message-id so it would not really be a new message.

> If a signature includes a useful hash of the message, it cannot survive 
> really extreme violence.  Hence, a signature cannot reasonably survive 
> transit through a mailing list that makes major changes to the message.
>
> DKIM cannot survive transit through some mailing lists and it is not 
> reasonable to make it try.

Your argument is not correct. It is well known how mail list behave and
it is not some extreme violence as you put it but well known system of
slight modification or none at all. This can be accounted for if you
really wanted to. Currently dkim can not account for all common cases 
especially when mail list software is aware of email mime structure and 
adds footer in appropriate mime-aware way.

>> 2.  Anyone who believes there are (or should be) no concerns should express 
>> them to the list, succinctly and concretely.

I do so state that having signature survive mail list is a concern if you
want something that works with current email architecture and it should be 
something that work group should try to account for if you want to have
a successful specification.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: John Levine <[email-masked]>
Date: 15 Mar 2006 04:15:00 -0000

>express them to the list, succinctly and concretely.

I don't see any concerns about mailing lists.  All I see is a lack of
clarity about the meaning of third party signatures.  Some list mail
will have only the original sender's signature, some will have only
the list host's signature (either because the original message was
unsigned or the list software mutated the message), some will have
both signatures.

Outgoing mail on my system originates from about 100 different
domains, because I host mail for a bunch of small local businesses,
and I also have a bunch of majordomo2 mailing lists.  My intention is
to sign all the outgoing mail, on the theory that if it's coming out
of my system, I'm responsible for it.  Some of my users (the nerds at
Cornell) may sign mail before submitting it here so it'll have both
the originator's signature and mine, the rest of the users' mail will
just have just mine.

>From a recipient's point of view, the meaning of my third party
signature on my users' mail is the same as the meaning of my third
party signarture on my list mail.  As far as DKIM is concerned, a list
is just another forwarder.  If we get the meaning of third party
signatures in general correct (which I don't think is hard), we've
dealt with list mail.

R's,
John

---

From: John Levine <[email-masked]>
Date: 15 Mar 2006 04:22:31 -0000

>field) and same message-id so it would not really be a new message.

I think that if you look at the overall world of list mail as opposed
to the old-fashioned lists that we nerds like, that's not true.  As
I've noted before, Yahoo Groups, the largest list host in the world,
does all sorts of exciting things to mail that passes through,
including editing ads into the HTML code of text/html and
multipart/alternative messages.  The list software I use, majordomo2,
routinely smashes HTML mail down to plain text, filters out MIME
parts, and otherwise rewrites mail in ways that no signature could
possibly survive.

Some signatures will survive some list software, some, probably most,
won't.  That's life, we can deal with it.  As I've said before, as far
as DKIM is concerned, a list is just an example of a mail forwarder.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Tue, 14 Mar 2006 20:39:37 -0800

>> potentially small additional mail-list footer and potentially change in
...
> does all sorts of exciting things to mail that passes through,

The meta-issue, here, is what a current batch of mailing list software systems 
might do, versus what mailings are allowed to do.

There is no specification that restricts what lists are allowed to do.

As lists attempt to facilitate more interesting types of group collaboration, 
for example, output that is a highly structured and varied formulation of 
messages that come in are not unreasonable to envision.

The danger of making design decisions based on a current batch is that the next, 
innovative list will break the signatures.  If we think that's ok, then fine. 
If we think we are making something that will be robust against all legitimate 
list behavior styles, then we are definitely *not* fine.

d/
-- 

Dave Crocker

---

From: Mark Delany <[email-masked]>
Date: Wed, 15 Mar 2006 04:39:48 +0000

> to the old-fashioned lists that we nerds like, that's not true.  As

What that all says to me is that we should be engaging current Mailing
List deployers/implementors. I note that the Sympa folk have a) done
some experimental DK work and b) have written some tentative blogs on
the matter.

Can we get more of these type of folk on-board to provide guidance?

Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 15 Mar 2006 00:27:39 -0500

----- Original Message -----
From: "Mark Delany" <[email-masked]>

> Can we get more of these type of folk on-board to provide guidance?

Mark,

I have provided numerous times what needs to be done to our  LS product. The
link provided in Symba's Wiki [1] summarized it.

In my opinion, and its no secret,  SSP is the answer.  SSP will help minimum
many uncontrollable DKIM  issues.  SSP is what sold me on DKIM when it was
first presented last year.  Unfortunately, the deemphasis or movement away
from SSP has made DKIM a lot harder to justify.

The logic all starts by following the SSP/DKIM Consistency chart [2] which
describes the absolute boundary conditions in the DKIM email model.

In short, the responsible DKIM domain must have a way to tell potential
verifiers and "resigners" (LS or not) how to best handle their DKIM
messages.

If the domain doesn't care about potential downlink problems, then it can
only expect to be using a relaxed policy and therefore should not have any
reasonable expectation for protection.   If he wants protection, then it
needs to declares the stronger, more 3PS restrictive or none/never policies.

I disagree with Dave that it is a "complex" issue.  No.  It is issue
regarding more changes to software.   If thats a barrier, then thats another
issue.  But it isn't complex in my opinion.

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

[1] http://www.sympa.org/wiki/doku.php?id=dkim_and_mailing_lists
[2] http://mipassoc.org/pipermail/ietf-dkim/2005q3/000239.html

---

From: Alan Thew <[email-masked]>
Date: Wed, 15 Mar 2006 10:53:09 +0000 (GMT)

> some experimental DK work and b) have written some tentative blogs on

LISTSERV now offers DK support.
-- 
Alan Thew                                       [email-masked]
Computing Services, University of Liverpool     Fax: +44 151 794-4442
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2006 11:51:05 +0000

> Can we get more of these type of folk on-board to provide guidance?

I've subscribed to that internet2 mace-mlist group's list and asked them
for their preferred answer to this question. We'll see if they're better
at reaching conclusions than this list:-)

If that's not the best place/group to ask, feel free to let me know
offline.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Mar 2006 11:58:11 +0000

Hi Alan,

> LISTSERV now offers DK support.

Can you summarise what it does? Ideally in terms that make sense given
the earlier discussion here.

Ta,
Stephen.

---

From: Alan Thew <[email-masked]>
Date: Wed, 15 Mar 2006 13:39:03 +0000 (GMT)

> the earlier discussion here.

I can't offer much, I work for a customer. They say it's based on

http://nis.nsf.net/internet/documents/internet-drafts/draft-delany-domainkeys-base-03.txt

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 05:40:08 -0800

Dave Crocker wrote:
> The meta-issue, here, is what a current batch of mailing list software 
> systems might do, versus what mailings are allowed to do.
> 

There will, however, be restrictions on who and how a domain's
name in origination addresses can be used soon enough. That is the basic
conflict.

> The danger of making design decisions based on a current batch is that 
> the next, innovative list will break the signatures.  If we think that's 
> ok, then fine. If we think we are making something that will be robust 
> against all legitimate list behavior styles, then we are definitely 
> *not* fine.

That assumes that mailing list software's perogatives
trump all. They don't. They need to be part of the larger
ecosystem here, and they certainly do not have a god-given
right to preserve the From: address and completely change
the content with complete impugnity. That is the attack
we are by and large trying to eliminate, or at least put
constraints on. If mailing lists insist on changing content
and breaking original signatures, then they should expect
being treated like any other forgery.

The object here is to reach an accommodation between these
two competing needs. But if I had to say who ought to lose
push come to shove, it would be mailing list software that
insists on changing my original content and then trying to
pass it off as if I wrote it. Given the microscopic percentage
of list traffic in comparision to the rest, that is not an
idle threat.

		Mike

---

From: Barry Leiba <[email-masked]>
Date: Wed, 15 Mar 2006 09:44:13 -0500

Hector points out something that I was planning to say about this: that 
it's really an issue for SSP (and so maybe that's the doc that's really 
held up by this discussion).  Here's how I see it:

 From a base-spec point of view, as Dave says, we have the length tag, 
the list of signed headers, and the canonicalization that all help 
protect signatures against existing mailing-list behaviour.  That means 
that the base spec mostly has the issue covered, and I think a brief 
discussion needs to be in there about what signers should consider with 
respect to mailing lists, and what mailing-list software developers 
should consider with respect to signatures.

The biggest issue that existing mailing lists have is what they do to 
the subject header, since we particularly recommend signing the header 
and since so many lists (including this one) modify the header.  And, in 
fact, many subscribers insist on that modification, even though they 
could filter on headers such as List-ID instead.

One note here: the base spec COULD suggest that if the signature fails 
to verify and the subject is signed and begins with "[", that the 
verifier might retry after removing the "[xxx]" part.  And then, much as 
with that part of the message that comes after the signed length, the 
verifier must decide what to do if the retry succeeds.

But in the worst case, the list has simply invalidated the signature, 
and we say that this SHOULD be considered equivalent to no signature at 
all.  Absent SSP, this is no bad thing.

When we add SSP in, though, we have to consider the issue of a policy 
that says "we sign everything" and a mailing list that breaks the 
signature and does not add its own (remember, we're talking, now, about 
existing mailing-list software that is not DKIM-aware).  I DO think the 
problem gets complex here, because we do not want to take this 
behaviour, which is now considered acceptable, and suddenly declare it 
to be "suspicious".  And yet bad actors could take advantage of this 
loophole.

Hector says:
 > SSP is what sold me on DKIM when it was

I don't think we're de-emphasizing SSP nor moving away from it.  What 
we've said is that DKIM signatures and keys are defined by a pretty 
mature spec that's gotten a lot of work put into it, but that SSP is 
much less mature and needs significantly more work.  And that we believe 
DKIM has value without SSP, so the work on SSP should wait until after 
the base spec is done.  We've allocated several months to work on SSP 
and, while some have opinions that differ markedly from Hector's about 
it, we DO aim to spend the time on it.

> needs to declares the stronger, more 3PS restrictive or none/never policies.

I don't think this considers the issue I discussed a couple of 
paragraphs up, where a signer wants to say that it signs everything, and 
a DKIM-unaware mailing list breaks the signature.  That is the very 
issue that was brought up in Vancouver, and that some are quite 
seriously concerned about.  The complexity isn't in the changes needed 
to mailing-list software; the complexity is in sorting it out WITHOUT 
causing existing mailing lists, which are considered well-behaved today, 
to be looked at suspiciously.

Barry

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 07:24:38 -0800

Folks.

> systems might do, versus what mailings are allowed to do.

The sentence was supposed to say:

The meta-issue, here, is what a current batch of mailing list software systems 
DO do, versus what mailings are allowed to do.

(In other words, current, limited reality, versus future, relatively unlimited 
possibilities.)

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 07:42:39 -0800

Michael,

> name in origination addresses can be used soon enough. That is the basic

I do not understand what this means.

And after you explain it further, please explain the basis for your certainty 
about the future you are predicting.

Not surprisingly, predictions about the future of specific networking 
activities/standards have had poor accuracy. Therefore, certitude about it is 
always worth explaining carefully.

>> the next, innovative list will break the signatures.  If we think 
>> that's ok, then fine. If we think we are making something that will be 
>> robust against all legitimate list behavior styles, then we are 
>> definitely *not* fine.
> 
> trump all. 

We are in a standards arena.  Therefore, the question of what "trumps" what 
needs to be based on standards, although a historical view of established 
practice of course useful.

Here are some relevant facts:

1. History: The world of mailing lists has shown a tendency towards considerable 
variation and has succumbed to standardization slowly and poorly.

2. The standards-based constraints on mailing list behavior are rather few, 
really.

3. If the DKIM effort is going to make assertions or decisions that constrain 
mailing lists beyond their current standards, then we a) must gain agreement 
that that is within our charter, and b) must specify those constraints and gain 
adoption of them.

I was under the impression that we must design something that lives within the 
realities of existing standards, rather than assume that the current 
implementations represent the complete range of choices.  (And, by the way, I 
suspect that existing range is rather wider than you believe.)

They don't. They need to be part of the larger
> the content with complete impugnity.

Well, pretty much, they do.

Absent violations of an Internet standard, a mailing list's software may make 
whatever changes the operator of the mailing wants or is willing to tolerate.

> two competing needs. 

I think that you think we are in a negotiation with the mailing list community.

We aren't.

d/

-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 07:54:32 -0800

>   And, in 

They could filter on it, but only when it is present and when the subscriber 
knows it is present.

Unfortunately, adoption of the List-* standard is pretty erratic and I suspect 
that most users don't know about these header fields at all, unless their mail 
client has features that use them.  Most don't.

Even for clients that implement the List-* construct, creating user filters that 
are based on the List-ID field requires quite a bit of sophistication.

> verifier must decide what to do if the retry succeeds.

Not only would that be building a heuristic into the validation portion of an 
otherwise precise security specification, it would be basing the heuristic on an 
undocumented convention that is far from universal, rather than on a a formal 
standard.

> all.  Absent SSP, this is no bad thing.

I am inclined to agree.  However the [] behavior is rather common.  So we 
probably should consider whether it is reasonable to have DKIM contain features 
that are intended to allow a signature survive mailing list transit, when we 
know that the final result will usually fail.

d/

-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 07:58:36 -0800

Dave Crocker wrote:
> Absent violations of an Internet standard, a mailing list's software may 
> make whatever changes the operator of the mailing wants or is willing to 
> tolerate.

With DKIM, they will be in "violation" of an Internet standard insofar
as they corrupt a legitimately signed piece of email, and preserve the
From: address. To a receiver, there is absolutely no difference 
between that case and the case that we'd like to guard against,
namely spoofing of From: addresses.

Mailing list software and their operators are perfectly at liberty
to stick their head in the sand, but I'm perfectly at liberty as
a receiver to treat mailing list email the same way that I treat
other likely forgeries. As it turns out, "I" being somebody who
lives and dies by mailing lists don't want to see that happen,
but "I" as the great unwashed masses of email operators could
probably care the least about the microscopic amount of list
traffic if DKIM adoption me a better user experience on the
fraud/phishing front.

> I think that you think we are in a negotiation with the mailing list 

"Negotiation" and "community" are your words, not mine.

		Mike

---

From: John Levine <[email-masked]>
Date: 15 Mar 2006 15:56:02 -0000

>Can we get more of these type of folk on-board to provide guidance?

I'm on the majordomo2 developer's list and maintain its qmail and VERP
interfaces, so I suppose I qualify.

Since mj2 uses the local MTA (sendmail, postfix, qmail, whatever) for
its incoming and outgoing mail, my expectation for the near term is
that we'll do nothing except perhaps to add DKIM-Signature: to the
list of incoming headers to strip on lists that mutate the mail enough
to break the signature, i.e., most of them.  For outgoing mail, the
MTA can do what it does.

Were I so foolish as to send in suggestions that we have to change or
limit mj2's functionality to conform to some DKIM or SSP thing, they'd
be met with derisive laughter.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, Mayor
"More Wiener schnitzel, please", said Tom, revealingly.

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2006 11:11:18 -0500

> name in origination addresses can be used soon enough. That is the basic

If you are planning on setting rules for lists about what they can do with
the mail that people send them, you might want to drop by Wikipedia and
read about the legend of King Canute.

I can just barely see some utility in SSP insofar as it describes a
domain's own policy, e.g., this domain signs all its mail or this domain
sends no mail.  As soon as it purports to control the activities of other
people, e.g., nobody can sign my mail but me, it leaps into the realm of
the unimplementable.

> That assumes that mailing list software's perogatives trump all. They
> don't.

Of course they do.  I run majordomo2, I like it just the way it is, and I
expect to run its output through my MTA that puts my domain's signature on
all its outgoing mail.  How exactly do you propose to make me do something
else?  (Hint: RFCs are suggestions, not commands.)  What will happen to me
if I don't?

> The object here is to reach an accommodation between these two competing
> needs. But if I had to say who ought to lose push come to shove, it
> would be mailing list software that insists on changing my original
> content and then trying to pass it off as if I wrote it.

Putting on my list owner hat, I would point out that if you don't like
what a list does to your mail, you are free not to send mail to it.  I
would be amazed if any list operators felt otherwise.

Regards,

PS: Was it you who put [ietf-dkim] in the subject line?

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 08:13:06 -0800

Dave Crocker wrote:
>> and we say that this SHOULD be considered equivalent to no signature 
>> at all.  Absent SSP, this is no bad thing.
> 
> 
> I am inclined to agree.  However the [] behavior is rather common.  So 
> we probably should consider whether it is reasonable to have DKIM 
> contain features that are intended to allow a signature survive mailing 
> list transit, when we know that the final result will usually fail.

   That's why I use the z= option, regardless of what the
   overly proscriptive -base spec says. I don't think this should
   in any way be part of the spec though as it is clearly a
   heuristic and depends greatly upon how much risk a receiver
   wants to tolerate.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 08:23:50 -0800

> From: address. To a receiver, there is absolutely no difference between 
> that case and the case that we'd like to guard against,

Oh.  Really?

Where is the standard that says that a mailing is is required to preserve 
specific pieces of information from a message posted to it?

Folks keep forgetting that a mailing list agent is a user agent.  User agents 
can do whatever they want, absent formal specifications to the contrary.

> other likely forgeries. 

The problem, here, is that it is not about forgery.  It is about designing 
mailing list software to do things that mailing list users find useful.

The fact that some things they find useful might have an impact on DKIM's 
ability to be forwarded is unfortunate, but is a long way from illegal.

> "Negotiation" and "community" are your words, not mine.

Please consider using them, since I believe they describe your assumptions 
rather accurately and concisely.

To the extent they don't, please explain.

d/
-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 08:23:18 -0800

> else?  (Hint: RFCs are suggestions, not commands.)  What will happen to me

   If you don't care whether your subscribers get their mail, nothing.
   If you do, then maybe you'll start listening rather than sneering.

> would be amazed if any list operators felt otherwise.

   Putting on my domain's receiver hat on, you are perfectly
   at liberty to send into my black hole. You are a very small
   and inconsequential domain. Do you really think that I'm going
   to care about your whinging as you hit the event horizon?

   People are in denial if they think that mangling mailing lists
   are anything other than inconsequential noise, and a fine candidate
   for collateral damage if that's the easier/safer path.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 08:27:05 -0800

>> contain features that are intended to allow a signature survive 
>> mailing list transit, when we know that the final result will usually 
>> fail.
> 

Use of the option seems like a reasonable idea.  However I am not sure how it 
gets used at the validating end.

That is, I do not see what the expected scenario is, once the difference between 
original Subject and current Subject is detected.

d/

-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 08:37:53 -0800

Dave Crocker wrote:
> 
> 
>>> I am inclined to agree.  However the [] behavior is rather common.  
>>> So we probably should consider whether it is reasonable to have DKIM 
> Use of the option seems like a reasonable idea.  However I am not sure 
> how it gets used at the validating end.
> 
> That is, I do not see what the expected scenario is, once the difference 
> between original Subject and current Subject is detected.

   It's all rather simple: if the change is "acceptable", for some value
   of "acceptable", you use the z= header instead of the actual header.
   Pretty much what Barry outlined.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 08:33:40 -0800

>> namely spoofing of From: addresses.

   Yes, really. It is explicitly part of SSP and the From: binding.

> Where is the standard that says that a mailing is is required to 
> preserve specific pieces of information from a message posted to it?
> 
> Folks keep forgetting that a mailing list agent is a user agent.  User 
> agents can do whatever they want, absent formal specifications to the 
> contrary.

   And user agents can also spoof From: addresses in hopes of
   getting Big Bux(tm) from unwary receivers. What's your point?
   We're trying to limit that degree of freedom by introducing
   cross domain authentication to the mix. Mailing lists are
   caught in the middle of this because they look for intents
   and purposes the same as the bad actors we'd like to put
   into a smaller box.

> The fact that some things they find useful might have an impact on 
> DKIM's ability to be forwarded is unfortunate, but is a long way from 
> illegal.

   "Illegal" is a loaded term. They might break DKIM signatures.
   Receivers may take different action based upon that broken/
   missing signature, regardless of how nobel and wonderful the
   intent was in changing the message while preserving the
   originating From: address. To the receiver, it all looks
   the same as some random spoofer.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 08:52:07 -0800

>   Yes, really. It is explicitly part of SSP and the From: binding.

1. SSP is not a standard (yet) and there is agreement that it is not all that 
mature. Hence, we cannot yet know what changes are going to be made to it. 
Given the nature of discussions about SSP, the changes could reasonably be 
expected to be considerable.

2. When SSP does emerge, its use is not going to be required for all DKIM 
signing, nor should it be.

Folks seem to be viewing aspects of SSP as if they were a) already resolved, and 
b) part of the core specification, rather than incremental to the base.

The base specification has exactly one bit of normative text involving mailing 
lists (5.5 Computer the Message Hash).   It does not say anything relevant to 
the assertions you are making.

>   getting Big Bux(tm) from unwary receivers. What's your point?

My point is that you are a) confusing legitimate behavior with nefarious 
behavior, and b) confusing formal specifications with common practice within a 
relatively narrow community.

>   and purposes the same as the bad actors we'd like to put

I do not understand what you mean.

>   "Illegal" is a loaded term. 

Violate the standards.  Contrary to, or forbidden by, law.

We are in a standards arena, so I think it entirely reasonable to distinguish 
between formal requirements versus anything else.  What you say is 'loaded' I 
say is 'precise and accurate' for a standards discussion.

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 08:53:59 -0800

>> That is, I do not see what the expected scenario is, once the 
>> difference between original Subject and current Subject is detected.
> 

So, you wish to specify that a security validation step rely on a heuristic?

Further, the definition of "acceptable" is pending.  For example, what are the 
variations between the original header and the new header that are acceptable?

d/
-- 

Dave Crocker

---

From: Steve Atkins <[email-masked]>
Date: Wed, 15 Mar 2006 09:09:08 -0800

On Mar 15, 2006, at 7:58 AM, Michael Thomas wrote:

>> Absent violations of an Internet standard, a mailing list's  
>> software may make whatever changes the operator of the mailing  
>> wants or is willing to tolerate.
>

Treat them as unsigned, you mean?

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 09:11:58 -0800

Dave Crocker wrote:
> 
>>> Use of the option seems like a reasonable idea.  However I am not 
>>> sure how it gets used at the validating end.
>>>

   I have already said that I'm not in favor of "specifying" this.
   "Acceptable" is left as an exercise for the reader.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 09:16:58 -0800

>   "Acceptable" is left as an exercise for the reader.

The question is about validation robustness against change, and about the 
contents of DKIM specifications, to deal with this question.

I do not understand the benefit of leaving such a major issue un-specified 
within normative text, particularly when you seem to be relying on the 
unspecified behavior to resolve the matter.

d/

-- 

Dave Crocker

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Mar 2006 09:36:18 -0800

>unsigned or the list software mutated the message), some will have

+1

At 8:39 PM -0800 3/14/06, Dave Crocker wrote:
>The meta-issue, here, is what a current batch of mailing list 
>software systems might do, versus what mailings are allowed to do.
>

Exactly right. And, given that, we cannot expect 
currently-functioning software to want to change just because a new 
standard is created years or decades after the software is deployed.

We dealt with this same issue in the S/MIME and OpenPGP working 
groups. Neither group came out with restrictions on how mailing lists 
should act, for good reason.

At 9:44 AM -0500 3/15/06, Barry Leiba wrote:
>One note here: the base spec COULD suggest that if the signature 
>fails to verify and the subject is signed and begins with "[", that 
>the verifier might retry after removing the "[xxx]" part.  And then, 
>much as with that part of the message that comes after the signed 
>length, the verifier must decide what to do if the retry succeeds.

Doing so would a poor security protocol. For one thing, some list 
software adds different insignia at different places. For another, it 
is an invitation to spammers to resend mail that didn't have [] at 
the beginning of the subject to resend with their spam between the [].

It is far safer to assume that any of the signed headers might be 
broken, and to encourage systems (such as mailing lists) that are 
known to break DKIM signatures to sign after they break them.

--Paul Hoffman

---

From: Eliot Lear <[email-masked]>
Date: Wed, 15 Mar 2006 09:43:37 -0800

> mailing list transit, when we know that the final result will usually

Is this one case where DKIM could have an impact on list configuration
behavior?

Eliot

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Mar 2006 11:08:55 -0800

On Mar 15, 2006, at 7:58 AM, Michael Thomas wrote:

> With DKIM, they will be in "violation" of an Internet standard  
> insofar as they corrupt a legitimately signed piece of email, and  
> preserve the From: address. To a receiver, there is absolutely no  
> difference between that case and the case that we'd like to guard  
> against, namely spoofing of From: addresses.

I agree with Dave Crocker.  Guarding the From: address is not the  
goal, as such would be futile for many reasons not fully detailed in  
the threat document.  The DKIM signature provides a strong indication  
who provided the content of the message.  While the signature may  
encompass various header fields, anti-phishing efforts MUST NOT  
depend upon the From address being spoofed or not.  Internal to  
Cisco, messages are being marked.  Such a strategy does not require  
the world change in an effort to conform to unrealistic SSP  
requirements.  Don't break email.

-Doug

---

From: Barry Leiba <[email-masked]>
Date: Wed, 15 Mar 2006 14:12:24 -0500

>> verifier might retry after removing the "[xxx]" part.  And then, much 
>> as with that part of the message that comes after the signed length, 
>> the verifier must decide what to do if the retry succeeds.
> 
> Not only would that be building a heuristic into the validation portion 
> of an otherwise precise security specification, it would be basing the 
> heuristic on an undocumented convention that is far from universal, 
> rather than on a a formal standard.
> 
> 

Dave, your two comments here seem contradictory: "We shouldn't try to 
handle '[]', because it'd be heuristic, but we should try to handle '[]' 
because it's rather common behaviour."  Do you have any ideas for 
handling it that don't throw us into heuristics?

I don't think there's a problem with verifiers applying some heuristics 
to this, given that (1) the signature is making a weak statement, and is 
not mean to be strong security and (2) this whole evaluation (the 
verification) is feeding into heuristics anyway ("What do I do with the 
message, given all the input I have about it?").

I appreciate Paul's comment, though, about spammers using that to their 
advantages.  Maybe it's part of the next-stage heuristics, where some 
hypothetical verifier considers "[ietf-dkim]" to be OK, "[Buy-Viagra]" 
to be <whatever>, and "[Come visit us at http://spam.example.com]" to be 
junk, using whatever next-stage heuristics it chooses.

I'm just afraid that the "[listname]" custom is sufficiently common that 
if we DON'T deal with it, we're throwing away too much opportunity to 
play nicely with existing well-behaved mailing lists.  So I'd LIKE to 
try to come up with a recommendation that helps (not a requirement, and 
not perfection).

Barry

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 15 Mar 2006 14:15:08 -0500

Hi, Barry,

I think we are in general agreement.  I'm just trying my best to see how to
make sense out of DKIM.   Who knows maybe DKIM is simply not a consideration
for the MTA software.  Maybe it should be left for sysops to implement on
the external edges.

But if its something we are to consider for implementation into our
framework, well, I can only tell give you my honest engineering assessment
because in the end, it all has to make sense for our customers and for our
support staff as well.  We will not going to introduce something that will
cost more in support.

In a direct 1 to 1 topology, a  signature is expected to survive.

In a topology where there is middle ware, the ideal "backward compatible"
model is to describe what it will take to make sure the signature survive.

You can't do anything about legacy software and it would be the
responsibility of the DKIM domain to be well aware of the repercussions of
submitting signed mail into a world of unknowns.  He can not expect it to
survive.

However, If we are being asked to find out what it will take to allow DKIM
signatures to survive a mailing list in a modern, still supported software
market, well,  I think SSP is cost effective way to control the impact and
also help keep the DKIM security blanket intact.

What I do not accept (or rather do not normally work as such) is the
incremental "fix it later" design approach when the most obvious is right
there in front of us.    It is unreasonable to expect that verifiers will
emerge simply to extract the valid messages of a 80% chaotic sea of
uncertainty, and to ignore those that purport to be DKIM ready yet fail for
some unknown reason.  This is unreasonable and it is makes DKIM harder to
justify.

My main points are can be summarized and itemize as such:

1) Recognize we do have legacy software and to do our utmost to help
minimize impact.

2) Recognize we do have current supported software and to do our utmost to
help prepare them to minimize impact.

3) Recognize and highlight to DKIM implementators to consider the impact
they will have on the potential damage of their domain reputation.

What does this mean?

Well maybe when targeting DKIM mail for a mailing list path, it might mean:

1) Binding consideration should probably not include the subject header
because it is at risk of being altered.  Same with any other header that is
subject to change in a list environment, i.e., Reply-To:

2) The length Z= tag should be used.

3) Consider not using DKIM domains at all for public list mail.

4) Use policies that help control the abuse.

DKIM domains need to take responsibility of what they are signing and do so
in appropriate manner to minimize impact.   A domain can not expect a
signature that is most often found to be abused (broken) most of the time,
to be viewed with trust the few times it is found to be successfully
validated.

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 12:16:37 -0800

> known to break DKIM signatures to sign after they break them.

And then what?

Everybody wants to hand-wave this issue away with the majikal "list 
signature",
but the reality is that they are not obviously useable to somebody who has
actually written lots of code in this area.

       Mike

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 15 Mar 2006 12:48:53 -0800

>    to care about your whinging as you hit the event horizon?

Are you sure you want to play the "whose domain is bigger" game?

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Mar 2006 13:48:58 -0800

>>known to break DKIM signatures to sign after they break them.

And then the receiver validates the signatures.

>actually written lots of code in this area.

They are not usable today because the -00 spec does not say how to 
handle multiple signatures. That can, and should, be changed in the 
spec.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 15 Mar 2006 21:50:16 -0000

>Is this one case where DKIM could have an impact on list configuration

Speaking as a list operator, if I have to choose between running my
lists the way that I've been running them for a decade and that my
users expect or using DKIM, DKIM will lose.

It is incumbent on us to design something that works with mail the way
it is, not the way we might wish it to be.  In the particular case of
mailing lists, list software has been changing message headers and
bodies for decades. Senders and recipients like it that way, since
those changes are mostly for the convenience of list users,
e.g. adding subject tags and flattening multipart or HTML to plain
text.  If we want the world to use what we design, we'd best design
something that can live with it.

The semantics of a DKIM signature is "you can blame me for this
message."  That's it.  When I get a message with a signature from a
signer I like, such as the operator of a list I've subscribed to, I'm
going to deliver it.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 14:05:09 -0800

> And then the receiver validates the signatures.

And then what? What would you have my receiver do differently just
because some random third party inserted a signature?

> handle multiple signatures. That can, and should, be changed in the spec.

That's not where the problem lies. In any case, we're only talking about
one valid signature since the mailing list torqued the original signature.

       Mike

       Mike

---

From: John Levine <[email-masked]>
Date: 15 Mar 2006 22:06:25 -0000

>known to break DKIM signatures to sign after they break them.

How about encouraging mailing lists to sign the mail they send,
regardless of how much they did or didn't mess with the messages on
the way through?

Lists have all sorts of ways of deciding what mail to accept, and
although some future list software might use DKIM signatures in some
part of that decision process, I expect most lists will continue doing
whatever works for them now.

I am much more interested in knowing that mail forwarde to me was
really forwarded by ietf-dkim than in how the list software selected
the mail to forward.  A list signature tells me that.

R's,
John

---

From: John Levine <[email-masked]>
Date: 15 Mar 2006 22:39:00 -0000

> because some random third party inserted a signature?

If it's a third party with a good reputation, accept and deliver the
mail, of course. If it's a third party with no reputation, you ignore
the signature, the same as a no reputation first party signature.

For example, I expect that at some point our list owner will arrange
for mipassoc.org to sign the mail from this list, mutated subject
lines and all.

Since mipassoc.org has never sent me any bad mail, and I know how to
contact him if there's a problem, what practical benefit would there
be to anyone from not delivering the mail his MTA signs and sends me?

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Mar 2006 14:18:48 -0800

>because some random third party inserted a signature?

There is no "random third party" here. It is a mailer that the user 
gets mail from. The signature would match the content of the message 
that they got, including list-specific content such as List-* 
headers, the possibly-munged Subject line, and the possibly-munged 
body.

What they would do differently is validate the signature, see that it 
is from someone who is supposed to be signing the message, and accept 
it, just like they do for regular mail.

>In any case, we're only talking about

If there is WG agreement that there can only be one DKIM signature 
per message, then the mailing list removes the existing signature and 
replaces it with its own. If there is WG agreement that there can be 
parallel or cascading signatures, then the mailing list adds its 
signature.

The fact that the WG has not yet decided how to handle multiple 
signatures does not mean that it won't in the future.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 16:16:58 -0800

Paul Hoffman wrote:

> that they got, including list-specific content such as List-* headers, 
> the possibly-munged Subject line, and the possibly-munged body.

How does a receiver know the difference between a "mailer" and a
"random third party"? Are you saying that you, Paul, can tell the
difference? That's substantially different than a piece of software
trying to do the same.

> it, just like they do for regular mail.

How do I, as a receiver, determine "who is supposed to be signing the 
message"?
It's not from the From: address as that's from the originating domain. 
And any
random spoofer can insert a Sender: and sign that message. You're making
pretty big assumptions that I, as a receiver, have any clue as to what the
relationship between the purported from and the mailing lists it 
traverses are.
In fact, we at Cisco have absolutely no clue about that at all, and I'd 
be pretty
surprised to hear that anybody of any size has any more clue.

> signatures does not mean that it won't in the future.

I'm not saying that. I merely said that your example does not require that
you drag that unfinished piece of business into the discussion.

          Mike

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 16:22:38 -0800

John Levine wrote:

>If it's a third party with a good reputation, [...]
>

And here's where we go off the rails. DKIM isn't doing reputation, and 
making
assumptions that reputation will save you is *every* bit as speculative as
making assumptions that mailing list software will change.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 15 Mar 2006 16:46:59 -0800

On Mar 15, 2006, at 4:22 PM, Michael Thomas wrote:

> John Levine wrote:
>
>>> And then what? What would you have my receiver do differently  
>>> just because some random third party inserted a signature?
>>
> And here's where we go off the rails. DKIM isn't doing reputation,  
> and making assumptions that reputation will save you is *every* bit  
> as speculative as making assumptions that mailing list software  
> will change.

For the most part, phishers do not attack unknown domains.  Such  
domains, irrespective of the From address, are recognized by the  
message content.  Better than 95% of the phishing exploits are  
blocked through rather simple message content heuristics, where  
DomainKeys or DKIM improves this figure substantially.  This is not  
reputation in the traditional sense.  Perhaps recognition would be a  
better term.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 15 Mar 2006 17:16:46 -0800

At 4:16 PM -0800 3/15/06, Michael Thomas wrote:
>"random third party"?

If the mailer also follows IETF standards that indicate that it is 
the mailer of the message, that tells the receiver something. Also, 
the receiver's software can simply ask.

>How do I, as a receiver, determine "who is supposed to be signing 
>the message"?

Anyone who is assumed to have sent the message can be assumed to sign 
the message. If that signature is from someone whom the receiving 
agent doesn't think is supposed to be signing the message, the agent 
can throw away the signature as irrelevant. Receiving agents will 
know that mailing lists might send the message without changing the 
From.

>You're making

It doesn't seem like a big assumption at all. RFC 2919, a standard, 
says exactly how a mailing list can say where the list is hosted. 
Even if the list doesn't use that standard, a receiving agent can ask 
a user "this message is signed by someone I don't know; does the 
domain lists.example.net seem like the sender of this message?". Many 
MUAs have this kind of capability now for moving mailing list 
messages into folders.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: John Levine <[email-masked]>
Date: 16 Mar 2006 01:41:46 -0000

> How does a receiver know the difference between a "mailer" and a

It doesn't, and it doesn't care.  It looks up the signing domain in
its handy local list of signers worth paying attention to.  Maybe at
some future time there will also be external sources of worthy
signers, but that's way outside the scope of any discussion here.

> How do I, as a receiver, determine "who is supposed to be signing

You certainly can't tell by examining the message.  If, say, I get a
message from Alexey Panov, even if it has a DKIM signature that
perfectly matches the From:. Sender:, SSP, and everything else, I
still don't want it.  And I doubt anyone else does, either.  This was
one of the few useful lessons people should have learned from SPF.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Wed, 15 Mar 2006 18:06:35 -0800

> signers, but that's way outside the scope of any discussion here.

Which handy local list of signers is that? Where do I find Cisco's?

		Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 15 Mar 2006 20:12:59 -0600

> Can you summarise what it does?

If anyone is interested, our MTA also includes a list exploder that has 
had to deal with this issue for a year now (starting with DK and now 
with DKIM).  I'm hoping that the collective wisdom on this list can 
eventually give us a BCP as I'm certain that I've gotten it wrong here.

Currently, I've taken the easy road (I guess) and the software will 
resign all list submissions on the theory "you break it, you sign it" 
and my list exploder always "breaks it".  I've experimented in the field 
(200 test customers) with stripping and leaving existing signatures in 
list messages.  There were no technical problems either way that I 
recall.  Due to an increase in queries regarding the presence of 
multiple signatures in the message I elected to make this an optional 
behavior and defaulted the software to strip.

It's been suggested that we recommend list vendors refrain from any 
modification of validly signed submissions (this was the thin model if 
memory serves?).  Although there's nothing wrong with this as an option 
and I would be willing to implement it - I don't think it would get much 
actual use in the field because I believe users want a visual indication 
in the inbox of list versus regular traffic.  Modifications to the 
subject are often the only way this is achieved.  Secondly, it's been my 
experience that MUA filtering is mostly done on the content of the 
subject line.  It would be nice if the List-ID were used for that 
purpose but that header isn't typically visible and so users don't 
always know to use it.  So, the subject is normally what they use.

I would love to eventually see us figure out what the best practices for 
list servers are and recommend those in some documented fashion.

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 18:51:04 -0800

Michael,

The signature that you are so worried about preserving is only useful if there 
is some database to consult, about it.

That's the list John is referring to.

So whatever you are planning to consult, after validating the originator's 
signature, is what should be consulted after validating the list's signature.

In other words, a valid signature is a valid signature.  An invalid signature is 
an invalid signature.

And, as I've raised many times, I do not understand the compulsion to preserve a 
signature for a message that is re-posted by an automaton user agent, when there 
is no equivalent expectation of preservation, for a message that is manually 
re-posted -- such as when I forward a message on to someone else.  The 
architectural role is the same.  The semantics are the same.

Mailing lists can do, and do do, whatever violence to a message they wish and 
their subscribers find useful, because the mailing list agent is really posting 
a new message, no matter how close it might seem to the original.  A small 
amount of hacking to make the close ones preserve the signature is one thing.  A 
large amount is quite another. So is attempting to declare the ones making 
larger changes "wayward".

It is not reasonable to try to declare that the ones doing small changes are 
somehow acceptable but that the ones doing larger are not, since a) there is no 
specification or established practice to justify that declaration, and has been 
pointed out rather directly, b) such a declaration will have no beneficial effect.

So, as vigorously as you are arguing your position, I am not seeing how it 
produces anything that will work in the real Internet.

d/

-- 

Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 15 Mar 2006 20:53:40 -0600

I also insert a Sender: header which matches the domain that does the 
signing so as to be friendly(er) with SSP.

-- 
Arvel Hathcock
CEO, Alt-N Technologies
http://www.altn.com

-----------------------------------------------------------------
MDaemon 9.0 is coming!  Superior multi-threaded IMAP, AntiVirus,
and AntiSpam performance, Active Directory monitoring, integrated
free/busy server, integrated SyncML server, plus so much more.
-----------------------------------------------------------------

---

From: "John R Levine" <[email-masked]>
Date: 15 Mar 2006 22:07:28 -0500

> Which handy local list of signers is that? Where do I find Cisco's?

Beats me.  If Cisco doesn't expect to be able to tell what signatures are
worth using, I can't tell what problem you expect to solve and I would be
most interested to hear what use you plan to make of DKIM.  Really.

In particular, experience with SPF suggests that the majority of mail with
valid signatures will in fact be spam, signed by the spammers.  Surely
you're not planning to put gold stars next to mail just because it has a
signature that matches the From: line.  Or are you?

R's,
John

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Mar 2006 00:30:38 -0500

On 03/15/2006 21:51, Dave Crocker wrote:
> The signature that you are so worried about preserving is only useful if
> there is some database to consult, about it.
>
> In other words, a valid signature is a valid signature.  An invalid
> signature is an invalid signature.
>
> And, as I've raised many times, I do not understand the compulsion to
> preserve a signature for a message that is re-posted by an automaton user
> agent, when there is no equivalent expectation of preservation, for a
> message that is manually re-posted -- such as when I forward a message on
> to someone else.  The architectural role is the same.  The semantics are
> the same.
>
> Mailing lists can do, and do do, whatever violence to a message they wish
> and their subscribers find useful, because the mailing list agent is really
> posting a new message, no matter how close it might seem to the original. 
> A small amount of hacking to make the close ones preserve the signature is
> one thing.  A large amount is quite another. So is attempting to declare
> the ones making larger changes "wayward".
>
> It is not reasonable to try to declare that the ones doing small changes
> are somehow acceptable but that the ones doing larger are not, since a)
> there is no specification or established practice to justify that
> declaration, and has been pointed out rather directly, b) such a
> declaration will have no beneficial effect.
>

This database that you insist is necessary for DKIM to be useful is pretty 
well by definition a reputation system.  So, if as you say a DKIM signature 
has no value without a reputation system of some limited kind and reputation 
is out of bounds, I guess I don't understand what you think we are doing 
here?

Scott Kitterman

---

From: Dave Crocker <[email-masked]>
Date: Wed, 15 Mar 2006 21:35:06 -0800

> is out of bounds, I guess I don't understand what you think we are doing 

creating an infrastructure.

(well, dkim also creates a bit of accountability, by my own view is that it does 
not mean much without an assessment component, too.  but as John Levine noted, 
it can be a small, internal table of well-known correspondents.)

if you think dkim has larger value, on its own, please explain.

d/

-- 

Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 16 Mar 2006 01:18:25 -0500

On 03/16/2006 00:35, Dave Crocker wrote:
> > This database that you insist is necessary for DKIM to be useful is
> > pretty well by definition a reputation system.  So, if as you say a DKIM
> > signature has no value without a reputation system of some limited kind
> > and reputation is out of bounds, I guess I don't understand what you
> > think we are doing here?
>
Unless one is in the business of selling infrastructure I don't know that it 
has any vlaue in it's own right.

> (well, dkim also creates a bit of accountability, by my own view is that it
> does not mean much without an assessment component, too.  but as John
> Levine noted, it can be a small, internal table of well-known
> correspondents.)
>
OK, so absent a reputation system it creates a bit of accountability then?

> if you think dkim has larger value, on its own, please explain.

In the long run, I don't know.  In the short run, as I've said before, I think 
the primary value is in highly phished domains using a restrictive SSP.  That 
gives me leverage to reject 'bad' messages.  We've discussed this before, so 
there's no need for yet another round of pointless fingerpointing on the 
value of SSP.

I was just curious since you seemed to have a very limited view of the value 
of DKIM without reputation.  

BTW, I'm about to drop off line for a while, so don't read anything into lack 
of responses for a bit.  If it's still relevant when I get back, I'll reply 
then.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 16 Mar 2006 02:15:26 -0500

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "Scott Kitterman" <[email-masked]>

>> So, if as you say a DKIM signature has no value without
>> a reputation system of some limited kind and reputation
>> is out of bounds, I guess I don't understand what you think
>> we are doing here?
>

DKIM is part of a new infrastructure, yet this "infrastructure changing"
expensive step has limited value?

What is the point of this excercise?

If you have a larger picture in mind, why don't you explain it to us?

> (well, dkim also creates a bit of accountability, by my own view is
> that it does not mean much without an assessment component, too.  but
> as John Levine noted, it can be a small, internal table of well-known
> correspondents.)

> if you think dkim has larger value, on its own, please explain.

On its own?

Well, SSP has been diminished so much I agree that DKIM has been reduced to
having very limited value at this point.  I put our DKIM coding budget on
hold!   DKIM sans SSP has limited protection vs. processing time value.

However,  we are now exploring adding FILTER rules using DKIM/DKEY
signatures (sans verification) as part of our scoring to filter out the
purest abusers.

   if DKIM/DKEY record exist
      and no DNS key policy exist, REJECT!

No hash verification (which fails most of the time anyway) required.

If this what you were looking for in a DKIM only environment?

This is something oddly wrong with this incremental design approach that
includes an expensive step with little or no value and in fact, may have a
major detrimental effect on the industry with its early DKIM-only pre-mature
promotion.

Sounds we can just toss DKIM aside and wait until this new reputation
trust-layer in introduced (or re-introduced).  But this can be done
independently anyway, so I am lost as too why  DKIM is needed in the first
place?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 06:34:31 -0800

> there is some database to consult, about it.

That is flat out wrong. We are right at this moment rolling out our
implementation of DKIM at Cisco. We have no local database. We are
getting utility our of DKIM by insuring our users to some degree
that the From address/domain that they see can or cannot be trusted to
the degree that DKIM makes that trustworthy. Y! and now Gmail from
what I hear are doing the same.

> preserve a signature for a message that is re-posted by an automaton 
> user agent, when there is no equivalent expectation of preservation, for 
> a message that is manually re-posted -- such as when I forward a message 
> on to someone else.  The architectural role is the same.  The semantics 
> are the same.

This is flat out wrong too. When you forward, you change the From:
address. Mailing lists do not. Therein lies the problem: they are
indistinguishable from random spoofers.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 06:52:30 -0800

> signature that matches the From: line.  Or are you?

This was all explained at the DKIM summit, whose slide I believe are
available on dkim.org. We are concerned about phishing attacks against
Cisco employees via spoofs purporting to come from Cisco itself. This
is a real life business affecting problem, and quite frankly it's
pretty frightening because the it's extremely difficult to tell what
is a bone-headed outsourced marketing scheme, and what is really trying
to steal your credentials, etc. This costs our Infosec people a great
deal of time and money sifting through the false positives that we
generate.

By signing all our mail and having a policy that we sign all our mail,
we can be reasonably certain that mail without a valid signature isn't
from Cisco and annotate the message accordingly. This works just fine
with the exception of mailing lists. What I'm trying to get a handle on
right now is to what _extent_ -- given our use of l= and z= -- it is a
problem. From what I can tell right now, for the "typical" mailing list,
it's going to validate. There is no question that some manglers will
never validate, and that there will be occassional blips on lists that
normally validate, but that seems acceptable given the threat we're
addressing. But we'll see.

Other companies -- who undoubtably use external mailing lists far,
far less than Cisco may never even perceive this as being a problem,
and just nuke the "spoofs" at the border. That's why I say that when
push comes to shove, mailing lists will almost certainly be the loser
unless we collectively come to some reasonable accommodation that
doesn't involve inventing a huge amount of work for the IT department
with "handy local lists".

		Mike

---

From: "John L" <[email-masked]>
Date: 16 Mar 2006 10:24:49 -0500

> We are concerned about phishing attacks against Cisco employees via 
> spoofs purporting to come from Cisco itself.

Oh, OK, then your trusted signer list includes cisco.com.  (Until a bad 
guy uses a zombie inside your firewall to send signed cisco.com phishes, 
but you can pretend to be surprised when that happens.)

> with the exception of mailing lists.

How many phishes have you ever seen that were sent through mailing lists? 
I've seen precious few, and in the unlikely event that it becomes a 
problem, list managers will have to deal with it, not just for Cisco. 
They'll doubtless deal using other tools than DKIM since it'll be a long 
time until DKIM is widely enough used to be any list's primary validation 
tool.

> From what I can tell right now, for the "typical" mailing list, it's 
> going to validate.

Mail from this list won't validate, you know, and I doubt that many others 
will, but I know I'm not going to make any headway in that direction.

In any event, Cisco will have to decide whether the actual cost of 
forbidding their employees to participate in lists that break signatures 
outweighs the theoretical benefits of blocking list-borne phishes.  If it 
does, you might consider adding known well-behaved list hosts to your 
trusted signer list.  I suspect you won't have to compile that list on 
your own, since we all plan to add them to our lists, too.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://iecc.com/johnl, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 07:37:21 -0800

John L wrote:
> Oh, OK, then your trusted signer list includes cisco.com.  

Not really, unless you consider SSP to be a "trusted signer list".

> (Until a bad 

This is actually a feature not a bug: we'll at least _know_ that the
phisher is coming from inside.

> How many phishes have you ever seen that were sent through mailing 

Irrelevant. Spoofs/phishes and mailing lists corruption are
indistinguishable to a verifier. And we can be guaranteed that
if you need to merely put a Sender: into a piece of mail to get
past the checking, phishers will most certainly do that. Which
is why we don't do allow that.

> Mail from this list won't validate, you know, and I doubt that many 
> others will, but I know I'm not going to make any headway in that 
> direction.

Every piece of mail I've sent this morning has validated. Really.

> outweighs the theoretical benefits of blocking list-borne phishes.  If 
> it does, you might consider adding known well-behaved list hosts to your 

We have no "trusted signer list". And we're not forbidding anything,
though other companies may and not blink an eye.

		Mike

---

From: "John L" <[email-masked]>
Date: 16 Mar 2006 10:50:03 -0500

> Not really, unless you consider SSP to be a "trusted signer list".

Oh, wow, are you really planning to reject all mail that fails SSP?  I 
guess we should have a pool on how long that will last until some VP blows 
up because it rejected some piece of real mail she really, really wanted. 
I'll bid on two hours.

> indistinguishable to a verifier.

Unfortunately, they are quite different to human beings.  Like I said, if 
you want to toss the baby out with the bathwater, it's your network, but 
you might want to check with some of your users to see if everyone's 
priorities are the same.

If you expect anyone other than you to start blanket rejecting list mail 
with signature problems, I think you will be rather disappointed.  As it 
is, I expect your support desk will have lots of fun explaining to your 
users why everyone outside Cisco sees the list mail they sent, but they 
and the people down the hall didn't get it.

> Every piece of mail I've sent this morning has validated. Really.

That's because it was all Re: and already had the subject line tag.  It's 
your lucky day.

Regards,

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 08:03:48 -0800

John L wrote:
> guess we should have a pool on how long that will last until some VP 
> blows up because it rejected some piece of real mail she really, really 
> wanted. I'll bid on two hours.

John, would you please try to read my notes instead of just
playing a parlor game with them. I said that we plan to annotate
the mail if it doesn't verify. We're not idiots, and it's a
disservice to the entire community that you are treating us as
if we were.

> That's because it was all Re: and already had the subject line tag.  
> It's your lucky day.

Please try to stay within your own experience. You clearly have
no idea what you're talking about here. I've implemented this and have
*way* more experience at where the problem are and are not. You're
quite simply wrong, and it's not helping this working group when you're
spreading clearly false information.

		Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 16 Mar 2006 10:12:34 -0600

> That's because it was all Re: and already had the subject line tag.

I'm not sure that's correct.  The l= in Mike's signatures takes care of 
the bits appended by the list to the end.  The z= subject value can be 
used by verifiers to take care of the subject munging this list 
performs.  The verifier then simply replaces the subject text with the 
value from z= that was signed.  That's one way of solving the mailing 
list subject munging problem.

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 08:16:37 -0800

>> The signature that you are so worried about preserving is only useful 
>> if there is some database to consult, about it.
> 

It sounds as if you are imparting more requirements on the phrase "some 
database" than the term has on its own.

You just described a database of one entry, with a very specific *additional* 
semantic.  This a) requires listing the domain name(s) to be assigned the 
semantic, and b) the semantic that goes with this.  This all goes far beyond the 
DKIM base specification.

That this bit of database and semantic is easy to build is not the issue.

The issue is that it requires specifying the domain name(s) and treating them 
specially. That is a database.

>> user agent, when there is no equivalent expectation of preservation, 
>> for a message that is manually re-posted -- such as when I forward a 
>> message on to someone else.  The architectural role is the same.  The 
>> semantics are the same.
> 

You have confused some details that are different -- some of the time -- with 
DKIM requirements. Worst is that those requirements are not in the base 
specification.

With respect to the point that I was making, there seems to be no concern 
whether manual re-posting breaks a signature, but a great deal of concern when 
that re-posting is by a user-level automaton.

And, by the way:

1) Re-send is a form of user, manual forwarding.  It does not change the From.

2) Mailing list digests *do* change the From.

d/
-- 

Dave Crocker

---

From: Mark Delany <[email-masked]>
Date: Thu, 16 Mar 2006 16:37:04 +0000

> list subject munging problem.

And there-in lies dragons methinks. Do you physically replace the
Subject: so that the final recipient gets the pre-list content or do
you logically replace it for the purposes of verifying?

If the former, you'll likely irritate exactly 50% of the planet that
wants that extra goop, and, you've precluded the possibility of a
smart UA doing that selectively on a per-user basis.

If the latter, then the vector is open for abuse and you'll have to
hope for wide deployment of smart UAs to protect users from this risk.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 08:51:17 -0800

Arvel Hathcock wrote:
> performs. 

The DKIM base specification defines the z= parameter.

It does not define what to do with it.

In particular:

>The verifier then simply replaces the subject text with the 

This goes far beyond the specification.  While it might be useful, it is really 
a heuristic and it is not part of the draft that is seeking standardization.

d/

-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 08:52:46 -0800

> you logically replace it for the purposes of verifying?

But they're dragons that can be fought by those who wish
to fight them. Personally, I'm a fan of empowered maximized
acid orbs, with a Bigby's grasping hand for fun if they're
wimpy enough.

More to the point: these are all decisions that the receiving
software can make, and make with as little or as much granularity
as you wish to envision. There are many other possibilities
as well. I don't expect there is a one-size-fits-all solution,
which is why this entire area is unfit for standardization beyond
providing the base level tools.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 09:17:12 -0800

Dave Crocker wrote:
> You just described a database of one entry, with a very specific 
> *additional* semantic.  This a) requires listing the domain name(s) to 
> be assigned the semantic, and b) the semantic that goes with this.  This 
> all goes far beyond the DKIM base specification.

You've deleted the key word: "local". We have no local database.
We're just using the SSP semantics as defined today. There are
no "additional semantics"; they just the semantics of SSP.

> You have confused some details that are different -- some of the time -- 
> with DKIM requirements. Worst is that those requirements are not in the 
> base specification.

I can see that you're equivocating about "base". I've never claimed
that it was -base alone. It's -base in conjunction with -ssp. And
you still haven't refuted my point. Both you and John would do well
to actually get some real-life experience here.

> With respect to the point that I was making, there seems to be no 
> concern whether manual re-posting breaks a signature, but a great deal 
> of concern when that re-posting is by a user-level automaton.

It has _nothing_ to do with humans and automatons. It has
to do with the purported From: address; mailing lists that
mangle messages are indistinguishable from any miscreant that might
want to spoof your From: address, human or otherwise. I don't
know how to make this more clear, but I'm not sure that it
matters since actual experience seems to count for little to
you.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 09:20:37 -0800

> as you wish to envision. 

You appear to be confusing localized mechanism with Internet standard.  We are 
discussing the latter, not the former.

Any validator is free to add whatever cleverness they wish.  However the degree 
of cleverness or its usefulness does not give it status within the IETF 
specification.

d/

-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 09:18:02 -0800

> Not really, unless you consider SSP to be a "trusted signer list".

1. SSP is not in the base specification

2. SSP is not a stable specification.

So, citing SSP as if it were somehow an authority for this issue is both 
formally and technical inappropriate.  Formally because you are treating it as 
basic law when it is neither basic nor law.  Technically because that aspect of 
SSP really is defining special semantics for certain domains, and *that* is most 
certainly defining a list.

> Every piece of mail I've sent this morning has validated. Really.

Given that this mailing list messes with the Subject line, a successful 
validation requires implementing mechanism that goes far beyond the 
specification.  That that enhancement might be useful is not the point.  The 
point that it is not in the wg spec.

>> forbidding their employees to participate in lists that break 
>> signatures outweighs the theoretical benefits of blocking list-borne 
>> phishes.  If it does, you might consider adding known well-behaved 
>> list hosts to your trusted signer list.  I suspect you won't have to 
>> compile that list on your own, since we all plan to add them to our 
>> lists, too.
> 

Your description of the handling of signatures and non-signatures for messages 
having rfc2822.From addresses containing cisco.com is a wonderfully classic, 
functional definition of a trusted signer list.

d/

-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 09:32:30 -0800

Dave Crocker wrote:
> You appear to be confusing localized mechanism with Internet standard.  
> We are discussing the latter, not the former.
> 
> Any validator is free to add whatever cleverness they wish.  However the 
> degree of cleverness or its usefulness does not give it status within 
> the IETF specification.

Who is this procrustean "we"? People asked, I responded, and made
clear what I think is and is not appropriate for standardization.
If there's anything off-topic and inappropriate here, I'll trust
the wg chairs to say so, including inappropriately trying to
stiffle discussion around how this is supposed to work in reality.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 09:38:30 -0800

>> be assigned the semantic, and b) the semantic that goes with this.  
>> This all goes far beyond the DKIM base specification.
> 

Yes, you do.

At any rate: 1) the issue was whether you have a database, not whether it was 
local or global, and 2) you treat cisco.com specially and this requires listing 
cisco.com specially.  That listing is a database.

> We're just using the SSP semantics as defined to
>> You have confused some details that are different -- some of the time 
>> -- with DKIM requirements. Worst is that those requirements are not in 
>> the base specification.
> 
> I can see that you're equivocating about "base".

It is odd that you would class an effort to improve precision and accuracy as 
'equivocating'.

It is particularly unfortunate since you seem to be relying on facts and rules 
that have no formal status.  Whether they ever will is an important question, 
but it is purely a matter of conjecture.

  I've never claimed
> to actually get some real-life experience here.

Yeah.  John and I do seriously lack real-world experience.  Thanks for 
repeatedly pointing that out.

> mangle messages are indistinguishable from any miscreant that might

You are conflating mailing list manipulation issues with SSP From field 
enforcement issues.  The former is the topic for this thread.

And it would be interesting to see your response concerning the difference you 
seem to see, between breaking a signature for mailing list forwarding of 
individual messages, versus breaking a signature for messages contained in a 
mailing list digest.

d/
-- 

Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 09:39:39 -0800

>> Any validator is free to add whatever cleverness they wish.  However 
>> the degree of cleverness or its usefulness does not give it status 
>> within the IETF specification.
> 
> Who is this procrustean "we"? 

The IETF.  The DKIM working group.  The subject line. Probably all 3.

d/
-- 

Dave Crocker

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 16 Mar 2006 12:04:25 -0600

> hope for wide deployment of smart UAs to protect users from this risk.

Yeah, you're right.  It's a difficult problem.

-- 
Arvel

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 10:13:11 -0800

Dave Crocker wrote:
>>> *additional* semantic.  This a) requires listing the domain name(s) 
>>> to be assigned the semantic, and b) the semantic that goes with 
>>> this.  This all goes far beyond the DKIM base specification.
>>
>>
> At any rate: 1) the issue was whether you have a database, not whether 
> it was local or global, and 2) you treat cisco.com specially and this 
> requires listing cisco.com specially.  That listing is a database.

The issue was *specifically* whether we were supposed to carry
a *local* database. That's what both Paul and John were saying
that we'd have to do with respect to third party signatures. We
do *not* have any such database, nor do we have any plans to do
so, and yet we still see utility. You're just shifting the argument
and it's distracting and not germane to the original issue.

> repeatedly pointing that out.

Is it really that difficult to go to sourceforge, deploy Murray's
milter, and get some?

> And it would be interesting to see your response concerning the 
> difference you seem to see, between breaking a signature for mailing 
> list forwarding of individual messages, versus breaking a signature for 
> messages contained in a mailing list digest.

The two situations aren't even remotely comparable. A mailing list
digest comes From: the domain of the mailing list. A mailing list,
on the other hand, preserves the originating domain's From: and
possibly breaks that signature due to transmogrification.

		Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 16 Mar 2006 12:15:56 -0600

>> The verifier then simply replaces the subject text with the value
 >> from z= that was signed.  That's one way of solving the mailing list
 >> subject munging problem.
 >
 > This goes far beyond the specification.  While it might be useful, it
 > is really a heuristic and it is not part of the draft that is seeking
 > standardization.

This was offered simply to counter the idea that it's impossible to 
validate mail which has undergone a subject munge.

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 10:22:34 -0800

Michael,

I'm sorry that you missed that my response was sarcastic.

Unfortunately, it was the only way I could think of formulating a response that 
at least had a patina of politeness to it.

d/

-- 

Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 10:25:56 -0800

Dave Crocker wrote:
>>> Yeah.  John and I do seriously lack real-world experience.  Thanks 
>>> for repeatedly pointing that out.
>>
>>
> Unfortunately, it was the only way I could think of formulating a 
> response that at least had a patina of politeness to it.

I was well aware of your sarcasm. Which reinforces my point all
the more.

		Mike

---

From: Dave Crocker <[email-masked]>
Date: Thu, 16 Mar 2006 10:31:27 -0800

> validate mail which has undergone a subject munge.

And I think that this highlights the need to be extremely careful about what is 
being claim and what is being discussed.

This being a standards group, our task is to discuss global specifications that 
reach community consensus.  That means they represent a public, common 
understanding of what can and cannot be done.

Anyone is free to go beyond that understanding, but when they do, they are 
outside of this forum.  Unless a behavior is explicitly specified and agreed to, 
the other participants in the mechanism -- e.g., use of DKIM -- cannot know it 
will happen.  If they cannot know it will happen, they cannot plan for it.

d/

-- 

Dave Crocker

---

From: Barry Leiba <[email-masked]>
Date: Thu, 16 Mar 2006 14:44:29 -0500

Let me try to pull this discussion back a bit...

>  > is really a heuristic and it is not part of the draft that is seeking

On the Cisco discussion:
My understanding (Mike, please correct me if I misrepresent this) is 
that Cisco is primarily using DKIM, at least for now, to verify that 
mail purporting to be from cisco.com (and is TO cisco.com) is, indeed, 
from cisco.com.  To that end, when you look at an incoming "cisco.com" 
message, you see one of these cases:
1. It has a valid cisco.com sig.
2. It has a failed cisco.com sig.
3. It has no cisco.com sig.

For case 1, you're done, but see below.
For case 2, you check SSP and see that cisco.com signs all mail, and you 
have to decide what to do with it (again, see below).
For case 3, you check SSP and see that cisco.com signs all mail, and 
since this isn't signed, you toss it (or place it under other scrutiny).

This is "below":
To minimize the incidents of case 2, you use the z= tag in the 
signature, so that you can verify the sig with the ORIGINAL headers. 
You can then see WHICH headers changed in transit, and take action based 
on that.  Now, z= was in IIM for that purpose, but in forming the DKIM 
spec we decided to label it for diagnostic/tracing purposes, and not for 
signature verification purposes.  Of course, any implementation is free 
to implement.

So some of the "case 2" cases now become "case 1" cases.  For case 1, 
you have what amounts to a "reputation DB" that says "cisco.com is 
good."  (Alternative interpretation, see next paragraph.)

In any case, you can show mail with verified sigs to the users in some 
way that tells them that the "sending domain" (sorry Dave; we never did 
close on terminology here) has been verified.  Whether or not you've 
done something special with "cisco.com" in the previous paragraph, the 
end user can look at "cisco.com" and "verified", and be happy.  The user 
can also look at "nastyspammer.com" and "verified", and it's up to the 
user whether she's happy or not.  In this case, the user's brain is 
providing the "reputation DB".

Is that relatively close to what's happening?

--------------------------

Now there's the question of whether using z= for the purpose that Cisco 
(and, if the option is turned on, Alt-N) is using it for is "OK".  The 
DKIM spec does not say that that's what it for.  Moreover, the DKIM spec 
gives a clear and well defined method for verifying sigs, and the use of 
z= is not part of it.  So I'd say (as a participant, not in any "chair" 
capacity) that this doesn't meet the spec; that is, it isn't "compliant".

That may be perfectly OK -- every implementation, as I said above, is 
free to implement.  In Cisco's case, if this implementation is an 
internal thing, does anyone else care if it's "non-compliant"?  In 
Alt-N's case, I'd think it ought to be clear that if the option to use 
z= is turned on, it deviates from compliance with the DKIM spec.

Arvel, I'm curious: how do you explain that option to the administrator?

Barry

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 16 Mar 2006 14:48:32 -0600

> Arvel, I'm curious: how do you explain that option to the

I have not implemented this.  I mentioned it only as a possible way to 
deal with subject alteration.

However, if I were to implement it, I would definitely mention the issue 
of losing the [list name] prefix.  I would put warnings in both the user 
manual _and_ in a popup box that appears anytime the option is enabled. 
  I would also mention that re-tasking the z= for this purpose was not 
the intent of the authors.

At the risk of tossing out another lame idea:

One could also construct a new subject header of this form:

Subject: <signed data>  Warning, unsigned content - (old unsigned data)

This is less safe but at least gives a warning to the user and would 
have the [list name] construct present for filters.

Ok, I'm ready to get flamed.  LOL.

-- 
Arvel

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 16 Mar 2006 13:08:45 -0800 (PST)

> This is less safe but at least gives a warning to the user and would have the 
> [list name] construct present for filters.

And what if somebody makes a reply to that email?
(and then somebody else replies to that, etc...)

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 16 Mar 2006 16:00:59 -0500

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, March 16, 2006 2:44 PM

> Now, z= was in IIM for that purpose, but in forming the DKIM
> signature verification purposes.

I fail to understand something here.

Now you know this was incorrect and it needs to be an optional part of the
specification to address these middle ware integrity issues.  So what is the
problem?

I hope its not related to incompatible issues with the premature deploy
base.  IMO, DKIM-BASE is not ready for prime time without SSP protection and
coherent set of operational procedures around it.

Anyway, I asked related questions about Z= back in

http://mipassoc.org/pipermail/ietf-dkim/2006q1/002375.html
http://mipassoc.org/pipermail/ietf-dkim/2006q1/002408.html

and only got 1 response.

The way I view it is that software will need to be selective on what is
hashed depending on where it is targeted.  I use my AMEX on certain
restaurants because it give me a "higher credentials" and I use MC/VISA on
others.  Same thing with DKIM. I am not going to use my most high-valued
DKIM security domains in the public mail list. However, I might if I knew
that the LIST SERVER will support it properly.

So again, its about having upfront knowledge on where you are sending mail
too.

My MTA can have it all setup:

    Mail TO:  CISCO.COM  -->   My signer will use HIGH-VALUE domain.
    Mail To:  MIPASSOC.ORG -->  No signing or a Relaxed Policy.

I know that CISCO.COM will 100% honor the security.  There is no guaranteed
MIPASSOC.ORG will. And even if they did, I expect destructure of the
original signatures and resigning of the distribution. So I have no choice
but to provide a relaxed domain to him, even if they honors SSP or not.

PS: I am willing to write a DRAFT I-D For "List Server DKIM Support
Recommendations."   Is that still desirable?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 16 Mar 2006 14:24:55 -0800

> since this isn't signed, you toss it (or place it under other scrutiny).

   We're actually not differentiating case 2 and 3 and we're never
   tossing the mail, only annotating it as "unverified" (we haven't
   actually had the debate about what precisely the annotation says,
   but I'm sure it will be a long one).

 > signature, so that you can verify the sig with the ORIGINAL headers. You
 > can then see WHICH headers changed in transit, and take action based on
 > that.  Now, z= was in IIM for that purpose, but in forming the DKIM spec
 > we decided to label it for diagnostic/tracing purposes, and not for

   Right.

 > good."  (Alternative interpretation, see next paragraph.)

   No, we're just using the SSP settings for the domain, and that's
   it: if the DKIM signature works, no annotation. If it doesn't and
   its SSP is set to o=!, you get annotation. As such, we're
   doing this primarily for ourselves, but if -- oh say -- IBM were
   to start signing their mail with o=! policy, IBM would be afforded
   the same annotation on failures. This is sort of like what Yahoo!
   is doing with their web interface, but much more crude -- but
   hopefully not very intrusive on the other hand.

 > user whether she's happy or not.

   Correct, though we only annotate in the negative sense, ie when
   we think there's something wrong via -base and -ssp.

 > In this case, the user's brain is

   I'm not really sure I'd call it a reputation DB, per se, even in our
   wetware. I guess it's mainly because of the negative sense of our
   annotation. But this is probably just an issue of getting the
   semantics right -- "reputation" leaves me feeling really disjoint
   from that is actually going on.

 > z= is turned on, it deviates from compliance with the DKIM spec.

   I'm not terribly hung up on whether something is "in" or "out"
   of spec because this is completely a local decision whether to
   do this sort of robustness/risk tradeoff. Nor do I think this
   would be a good thing to put in the spec. As I've alluded to before,
   I'm much more comfortable calling this an experiment and seeing
   where the data leads us.
		
		Mik

---

From: John Levine <[email-masked]>
Date: 16 Mar 2006 23:33:42 -0000

>However, if I were to implement it, I would definitely mention the
>issue of losing the [list name] prefix.  I would put warnings in both
>the user manual _and_ in a popup box that appears anytime the option
>is enabled.

I suspect users would not consider this this to be an improved user
experience.  If you were to go down this road, which I do not
recommend, I expect you'd end up with a database (shared or private)
of lists and tags so you could skip the warning when the difference is
the tag that the list is expected to insert.  Ugh.

As I've said before, I'd rather encourage list owners to sign their
mail and use those signatures instead to whitelist lists from
well-behaved sources.

>Subject: <signed data>  Warning, unsigned content - (old unsigned data)

And the unsigned data includes [Dial 800-555-2368 for herbal Vi@gra!]

Bad guys are clever, and we must assume they will drive a truck
through whatever opening we give them.  This strikes me as one that is
particularly ripe for abuse.

R's,
John

---

From: Tony Hansen <[email-masked]>
Date: Mon, 20 Mar 2006 00:30:39 -0500

Dave, I disagree. We are defining how to verify a message. If we agree
that the mechanism below is a reasonable step to perform, it's still
just one more step in the verification process.

	Tony Hansen
	[email-masked]

Dave Crocker wrote:
> In particular:
> 
>> The verifier then simply replaces the subject text with the value from
>> z= that was signed.  That's one way of solving the mailing list
>> subject munging problem.
> 
> This goes far beyond the specification.  While it might be useful, it is
> really a heuristic and it is not part of the draft that is seeking
> standardization.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 20 Mar 2006 00:33:55 -0500

I think it will eventually be worth having such a document.

	Tony Hansen
	[email-masked]

---

From: Dave Crocker <[email-masked]>
Date: Mon, 20 Mar 2006 07:25:37 -0600

> just one more step in the verification process.

Tony,

Do you disagree that it is a heuristic?  If so, please point me to the document 
-- preferably standard -- that specifies the format that will be checked and 
suggest what percentage of mail, of that class, will be covered by this mechanism.

My point in noting that this is a heuristic is not to say that heuristics are 
not useful.  Heuristics are wonderful.

However they are poor -- or at least dangerous -- for use within core algorithms 
of an interoperability specification.  A heuristic is a guess.  You are 
supporting the use of guesswork in a core algorithm for DKIM.

If it is really not a problem to have heuristics in a basic algorithm such as 
signature validation, then we ought to be able to find a solid history of their 
standardized use in interoperability protocols, preferably in IETF.

If we cannot find that history, we ought to be rather cautious about their 
inclusion in DKIM's basic validation mechanism.

d/
-- 

Dave Crocker