Subject: Attempted summary (was: Re: [ietf-dkim] DKIM and mailing lists)

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jan 2006 15:35:10 +0000

Let me try to summarise this thread so we don't have to do it
all again (or at least not too often:-)

Please correct where I've missed things, or gotten stuff wrong.

Where a particular message seems to contain a bunch of potentially
useful text, I've included a link to the archive. Note that I
don't mean that I think every word of the linked message is
perfect, more that a document author might find it useful to
go back to those messages.

Stephen.

The thread was kicked off by this post:

[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001753.html]

Discussion ensued:

- Mailing list servers can be thin (where they don't disturb
existing DKIM signatures) or thick (where they do disturb a
pre-existing signature). There might even be intermediate cases
but both approaches are reasonable and its not our job to argue
for one over the other.

[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001762.html]

- There is merit in mailing lists DKIM signing messages -
verifiers might be willing to whitelist some such mailing
lists. This applies regardless of whether or not the message
sent to the list was originally DKIM signed or not.

[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001818.html]

- If the message sent to the list was originally signed, there
can be merit in preserving the signature so that the original
signature on the message received from the mailing list could
still be verified.

- There are arguments that supporting both original and
mail-list signatures would be useful, but there are
also difficulties with this in particular adding the
mail-list signature will often break the original
signature. (If the mail-list signature only covers
the content and certain headers like List-Id then
this might work better).

- Some particular headers may cause difficulty when a
mailing list is re-signing an originally signed message (e.g.
"Reply-To", "Subject").

[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001821.html]

- The "l=" approach to modifications performed by mail
lists might, or might not, be worthwhile.

[Couldn't find that post when I went looking;-(]

- There may be merit in a mailing list considering the SSP
of the original message's domain before deciding how to
process the message.

[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001774.html]

- SSP was suggested as being a useful check to make during
subscription processing. (Although there was no feedback on
the suggestion, or else I missed it.)

[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001816.html]

- There may be implementation issues that warrant consideration
since mail-list code may be separate from the inbound and/or
outbound mail handling code => processing of DKIM could be
happening in different code bases.

[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001774.html]

- We have a few different (though not necessarily conflicting)
proposals for MUST/SHOULD/MAY language that can be considered
later on.

[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001781.html]
[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001800.html]
[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001810.html]

- There are reasons to not add >1 From to the message.

[http://mipassoc.org/pipermail/ietf-dkim/2006q1/001825.html]

My conclusions:-

- There are conflicting possibilities allowed by the above,
but each of the possibilities may be sensible. In other
words, there is not a unique correct design that meets all of
the above (and other real world) requirements. So the WG probably
need to flesh out a few practical use-cases and try satisfy
those.

- Are there any documented surveys on the things that
mail lists actually do? If so, I'd be interested in that for
my own education. But we might also be able to use such a
document to decide which use cases to try support. I don't
think we need to get the ultimate survey document, but if
there's something we can all agree lists some good-to-support
cases that'd be enough. Of course, since no-one's posted a
link that I spotted so far, that probably doesn't exist.

_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

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

> Where a particular message seems to contain a bunch of potentially

The mailing-list summary missed what should be serious concerns  
related to replay abuse, whether it is a list-server, free email- 
address provider, newsletter, or large domain.

Even aggressive rate restrictions, outbound filtering, and banishing  
offending email-addresses will not offer an effective solution for an  
abusive replay problem.  When a common key is used, key revocation is  
not practical.  Per-user keys or per-user policies will impact the  
related overhead, as both approaches will tend to overwhelm  
caching.   A bad actor is capable of sending replays from tens of  
thousands of sources simultaneously.  The use of a user policy as a  
means of control also unfairly impacts use of the email-address in  
cases where the recipient is the bad actor.  Even rapid responses  
from abuse reporting to pushing out altered key or policy with  
extremely short TTLs will still likely be too slow to be an effective  
deterrent.  Short TTLs with per-user records will likely increasing  
the related overhead further still.

Eliot suggested list-servers (free email-address providers,  
newsletters, e-invites, photo-kiosks, etc.)  be picky about who they  
allow to use their services, but did not provide a description of  
that process.  The current practice exercised by list-servers is the  
use of double opt-in and banning those abusing their privileges.   
Neither of these approaches protects the reputation of the list- 
server signature, or the reputation of the signing domains that pass  
through the list-server without the signature being overlaid with  
verification results.  A bad actor can issue a series of links, much  
as seen in the prior message, which look okay until being used in an  
abusive replay.

When there is replay abuse, how should the sender react?

What obligations do list-servers have with respect to their  
participants in regards to a replay abuse problem that may affect the  
reputation the signing domains sent through the list?

-Doug

P.S. Could you enclose your links in <> rather than [], thanks.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jan 2006 18:03:20 +0000

Douglas Otis wrote:
> The mailing-list summary missed what should be serious concerns related 
> to replay abuse, whether it is a list-server, free email-address 
> provider, newsletter, or large domain.

To whatever extent replay is an issue that we need to tackle, its
an issue that's not specific to mailing lists, which is why I omitted
it here.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Jan 2006 10:23:08 -0800

On Jan 23, 2006, at 10:03 AM, Stephen Farrell wrote:
> an issue that's not specific to mailing lists, which is why I  
> omitted it here.

Unless or until there is a better solution, a signature overlay  
strategy may impact conclusions reached in the handling of "thin"  
list-servers.  It could be prudent, although perhaps somewhat  
premature as this strategy has not been reviewed by the group, to  
offer a precaution in this regard.

-Doug

---

From: Eliot Lear <[email-masked]>
Date: Mon, 23 Jan 2006 19:26:08 +0100

Doug,
> allow to use their services, but did not provide a description of that
> process.
One obvious approach is to check the reputation of the applicant.  But
this may not be needed for all lists, particularly moderated ones.

Eliot

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 23 Jan 2006 13:33:25 -0500

From: "Stephen Farrell"

> link that I spotted so far, that probably doesn't exist.

Do you mean a survey of common mailing list features, or basic mailing
list mail flow operations?

Hmmmmmmmm, ok. I am seeing a trend here that is kinda throwing me for a
loop.

For all intent and purpose, the proposed DKIM/SSP protocol or any
similar protocol applies to all internet email operations, regardless of
what specific middle ware you have.   We can't selectively choose one
mail processor type over another.  They all have to work the same way in
relationship to the DKIM/SSP protocol.

We have a pretty wide spectrum of products for mail operations, from old
UUCP, SMTP, List Servers, News Servers,  Gateways, Groupware, News/Email
Gates, Fidonet, QWK, offline readers, online readers, etc, etc.

If we plan to add DKIM/SSP, it has to work and interface consistently
with everything where it is applicable and required.  One can't break
the other, and one can't benefit while the other does not.  Again, if it
is applicable.

The best we can do is to provide a basic EMAIL security technical
protocol, of course, with good engineering hindsight, and let the
authors fit it into whatever mail operations they have following 100%
the specs and guidelines.  Maybe that is what you are looking for, a
summary of general mail operations?

I just hope that LS operations does not become the exception to the
DKIM/SSP specifications.

Note, I'm not saying that the specs should not suggest guidelines as to
what a LS author might consider. That would be great. i.e. as a possible
suggestion:

    List Servers "MAY" consider restricting the type of DKIM
    policies it wishes to honor.  But under no circumstance,
    it MUST NOT break the integrity of DKIM messages.

The only squeaky issue is the idea of "stripping" for policies that
might allow it.  This might be acceptable because network control lines
(headers) has always traditionally been under the control of the network
mail processors.   But is stripping acceptable for a DKIM domain?

This is a big item because it will help define the complexity of List
Server DKIM processing.  If we declare no stripping of existing
signatures, even if an optional policy is used,  then that forces the
hand (a particular design requirement) we list servers authors have to
do.  Allowing us to strip will simplify a big part of the Relaxed
Policies issues.

Anyway, List Server or not, the same applies to any other middle ware
processor.  How about Mail Filter Agents (MFA)?  Automated responders?
and others.  They all need to follow DKIM/SSP in the same way.

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

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jan 2006 18:55:59 +0000

> list mail flow operations?

I'm not sure, probably the former. Let me try explain again.

Mailing lists (and others) do things that break signatures,
for good, bad and indifferent reasons.

If we want to define a protocol that allows for both original
and mailing list signatures, so that the one doesn't have to
interfere with the other, then we have to have some understanding
of how lists (and others) break signatures.

Probably a bunch of people on this list already know all about
this. I don't, at least not sufficiently well to judge some of
the options. So I'm asking for a pointer to the "how mailing
lists break signatures" report, if it exists so I can learn
a bit more.

Now, if that did exist, it might also be useful to folks who
already know all about this area in that it would give us a
way to say "if you do this it breaks when the message is handled
by things like those in section 9.1.32", or, "we defined this
field so that you can still verify even if you go through a
server like that in section 8.2.3 which is fairly common".
Being able to point at bits of such a report might help us go
quicker.

However, I can well imagine that this doesn't exist in any
usable form, but it'd be nice if it did.

Stephen.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 23 Jan 2006 11:05:50 -0800

On Jan 23, 2006, at 10:26 AM, Eliot Lear wrote:
>> newsletters, e-invites, photo-kiosks, etc.)  be picky about who  
>> they allow to use their services, but did not provide a  
>> description of that process.
>
> One obvious approach is to check the reputation of the applicant.   
> But this may not be needed for all lists, particularly moderated ones.

Even a moderated list would likely not be able to ferret out messages  
containing links that may, after being sent, transform into a website  
for spam or perhaps offer browser exploits.

When you say the reputation of the applicant, are you suggesting  
applications accompany a certificate to identify the individual?

Once messages have been signed, without an overlay strategy providing  
a means to hold the receiving domain accountable for not protecting  
signatures, controlling replay abuse demands perhaps impossibly rapid  
revocation of keys or policies.  The bad actor's strategy could  
easily stage replays when the administrator is asleep.

A bad actor is able to obtain tens of thousands of free email- 
addresses.  Only negative reputations for email-address may perhaps  
be safe to distribute, as any such list will also expose these email- 
addresses to spam abuse themselves.  Nevertheless, a negative  
reputation is reactive after the fact.  The reputation and associated  
reactions will be too late to be effective to abate a blitz replay.   
Messages will have been signed and can be disseminated in mass, well  
beyond the control of the list-server.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 23 Jan 2006 14:01:02 -0500

----- Original Message -----
From: "Douglas Otis" <[email-masked]>

Doug,

"Thin," slim, fat or gross, its all the same. Its common sense.

If you believe a replay problem exist with DKIM/SSP, then you have to
believe the replay problem exist now without it too.

So what is the difference?

---

From: Jim Fenton <[email-masked]>
Date: Mon, 23 Jan 2006 11:10:17 -0800

Thanks for the summary, Stephen.

> the content and certain headers like List-Id then
I didn't find the original mention of this, but I'm not clear on why
adding a mail-list signature would break the original.  It's just an
additional header field, and unless the original signature was
constructed to prevent that (by including DKIM-Signature in the h=
headers) there shouldn't be a problem.  What might break the original
signatures is the modifications to the message that necessitated the
mail-list signature.
> [http://mipassoc.org/pipermail/ietf-dkim/2006q1/001821.html]
I didn't get quite this meaning from Frank's message.  I don't know what
the difficulty is; the list just has to make any modifications it's
going to make before it re-signs.  Like Frank, I would prefer if lists
didn't do a lot of things they currently do to messages.  Nevertheless,
I realize that some lists are advertising-supported, so it's a behavior
we're going to have to deal with.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 23 Jan 2006 19:19:17 +0000

> signatures is the modifications to the message that necessitated the

You're right. Better if I'd said "The mailing list may change
fields of the message before signing, thus breaking the
original signature."

> we're going to have to deal with.

Agreed. Better if I'd said: "Changes to some particular headers
(e.g. "Subject", "Reply-To") and/or the body may cause difficulty
when a mailing list is re-signing an originally signed message."

Which is almost the same as the above I guess and probably not
worth saying twice:-)

Cheers,
Stephen.

---

From: [email-masked] (Wietse Venema)
Date: Mon, 23 Jan 2006 14:30:55 -0500 (EST)

> signatures is the modifications to the message that necessitated the

When the list server's DKIM signature covers a FROM: header with
an address in some unrelated domain, would not this be considered
a third-party signature? This would be avoided by having the list
sign only the headers that identify the list.

	Wietse

---

From: Jim Fenton <[email-masked]>
Date: Mon, 23 Jan 2006 11:45:53 -0800

> when a mailing list is re-signing an originally signed message."
Almost.  It doesn't cause a difficulty with re-signing, it causes a
difficulty with the original signature.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 23 Jan 2006 14:55:14 -0500

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>

> signatures is the modifications to the message that necessitated the

Right, so there are 3 designs a LS can take when content modifications
is desired by the list admin:

  - Strip, No Resign  (NEUTRAL, WEAK)
  - Strip, Resign    (NEUTRAL)
  - Resign  (NEUTRAL, STRONG)

Example:

1) An email is submitted to the list from a domain with a WEAK SSP.  The
email is signed by the original domain.  If the LS is intent on content
change, then its only recourse is a STRIP.  If the email was not signed,
then the LS can do what it wants as normal but *not* resign it.

2) An email is submitted to the list from a domain with a NEUTRAL SSP.
The email is signed by the original domain.  If the LS is intent on
content change, then it STRIP and/or RESIGN it. If the email was not
signed, then the LS can do what it wants as normal including resigning
it if it wants.

3) An email is submitted to the list from a domain with a STRONG SSP.
The email is required to be signed by the original domain.  If the LS is
intent on content change, then the LS can only RESIGN it. It can not
strip it.

So the logic is established and consistent with the SSP protocol. The
downlinks verifications will be safe as well.

> I didn't get quite this meaning from Frank's message.  I
> don't know what the difficulty is;

If the DKIM signature includes the hashing if a Reply-To: header, then
this will cause a problem for "modern LS" that use the Reply-To: as
RFC-ready MUA ergonomic kludge to resolve the issue of "layman" users
who naturally hit the reply button with the intent of replying back to
the list, but inadvertingly send it directly to the author.

So LS offer the options to fix the Reply-To: field as the List Address
and this makes it very easier for users to "naturally" reply back to the
list.  Otherwise, the user has to be aware of clicking "Reply to All"
(like I had to do now) in order to get the list address among the reply
list.  But this causes redundancy with multiple copies, which I really
do not want, but I am too lazy to remove the extra addresss :-)

This is an basically a RFC-ready Mail Reader issue that is "trained" on
a EMAIL vs NEWS concepts where the natural action for the reply button
is:

  EMAIL -> REPLY-TO:, FROM:
  NEWS  -> ALL

Without a Reply-To:, you have to click the unnatural "Reply to All"
button in other to get the list address.

Anyway, if the hash includes a Reply-To: then it breaks this feature
offering of a List Server.

---

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

> So I'm asking for a pointer to the "how mailing lists break
> signatures" report, if it exists so I can learn a bit more.

This was argued at some length about a year ago, but I can't
dig up offhand exactly where.  Here's some of the more popular
mutations:

- Add fixed list name tag and varying message serial number to Subject:

- Add, delete, or replace Reply-To: header

- Reformat From: line into a standard form, e.g.,  <a@b> foo  ->  a@b (foo)

- Add a bunch of extra headers like List-ID: and Precedence:
(shouldn't affect signature unless one replaces an existing header)

- Add a footer to the end of the body

- Add a "fronter" to the beginning of the body

- Add, delete, or reorder MIME parts

- Unpack and re-pack MIME parts with different delimiters

- Add a footer to one or more MIME parts

- Edit a footer into an HTML part (Yahoo groups does this)

- Convert HTML to text or vice versa

- Recode between 7bit and 8bit, or quoted printable to/from base64

I quickly came to the conclusion that other than the shrinking
minority of lists that do nothing at all to headers or body, it's
completely hopeless to try to make a signature that will survive list
processing.

And I still have a lot of trouble thinking of plausible scenarios
where mail from a domain with SSP restrictions would legitimately be
sent through a list.

R's,
John

---

From: Mark Delany <[email-masked]>
Date: Mon, 23 Jan 2006 20:07:13 +0000

On Mon, Jan 23, 2006 at 02:30:55PM -0500, Wietse Venema allegedly wrote:

> a third-party signature?

It could be. It's certainly something concrete that a verifier can act
on. We merely need to describe the desired actions.

> This would be avoided by having the list sign only the headers that
> identify the list.

That presents the same sort of risks that -l does. I would must prefer
the list sign the whole content and the spec define the verifier
semantics when a 3rd party signature is seen with, eg, a List-ID
covered by the second signature.

If well defined, those semantics should be able to achieve the
functional affect of your suggestion without the risk of sending
unsigned material.

Mark.

---

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

>   - Resign  (NEUTRAL, STRONG)

This appears this is using terminology that does not exist in the SSP  
draft, and related to a dropped policy described here as (NEUTRAL,  
WEAK), 'o=?'.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 23 Jan 2006 15:12:35 -0500

Stephen,

Ok, I see. I can provide my "feature list".  But all I was saying is
that, why should it matter? :-)

DKIM/SSP is an RFC 822 extended EMAIL protocol.  Mailing List or List
Servers and all other mail processors are augmented technology that fit
on top of the 822/821 model

So regardless of a extended mail processor features, its I/O, outer
edge, must be consistent with the expectations of the email system.

So you have:

    AUTHOR/822 ---->  whatever ---->  RECIPIENT/822

"Whatever" could of been a dozen transformations. Who knows!?  But the
governing rule of thumb is that what went in, should be what comes out
and we shoot for 100% maintaining the integrity.

So lets make Whatever a group of items that includes, all the basic
parts, including a List Server as well:

   MUA/MTA --> | MSA --> MFA --> LS --> MTA--> MDA | --> MUA

No matter what features you have, the input must equal the output.
That's the goal in all this.

The MUA/MTA comes with a DKIM/SSP header.  Nothing in the middle should
break it, and its known to do something that could break it, then either
the adjusts itself to DKIM or not.  But to do it correctly, it has to
adjust, especially if something in the middle is changing content.

Do you really want a list of features? <g>

The basic features of a general list server are pretty simple:

- Subscription control
     - open, close, open/confirm

- Submission Control/Options
    - Allow Posting?
    - Allow Any Poster?
    - Moderated?
    - Stripping
         - Attachments
         - HTML

- Expansion/Distribution Options
     - Set Reply-To Field to List Address
     - Keep Original To: Address
     - Auto-Unsubscribe for failed transactions
     - Body Headers/Footers
     - Additional 822 Headers

- Digest
     - Frequency
     - Size

- Request Files
     - Help via EMAIL

- Others options

Pretty basic stuff, and the above is a short list, but I tried to show
some items that might affect DKIM/SSP.

--- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Hector Santos" <[email-masked]>

>> Do you mean a survey of common mailing list
>> features, or basic mailing list mail flow operations?
>

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 23 Jan 2006 15:28:19 -0500

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>

>> Right, so there are 3 designs a LS can take when
>> content modifications is desired by the list admin:
>>

> draft, and related to a dropped policy described here as (NEUTRAL,

I believe the consensus has preliminary accepted the easier to
communicate terms in technical conversation, in fact, it appeared in the
last IETF meeting PowerPoint presentations by  Eric and Jim, I believe.

WEAK was proposed by Arvel to be added to SSP. I don't think it was part
of the original SSP draft.

I haven't checked the latest drafts, so I don't know anything about it
was added or "dropped policy."   Are you making things up again? <g>

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 23 Jan 2006 15:40:35 -0500

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>

> where mail from a domain with SSP restrictions would legitimately be

I agree with this. I think we are not giving the DKIM domain owner the
benefit of doubt. If he will bother with DKIM, he will be prudent and
will control his usage of his new "marked" domains.

But I can see plausible mail operations where a domain might want to use
a more relaxed policy for LIST submissions only and/or a LIST requiring
that all submitted mail be DKIM signed using relaxed policies.

The goal being to protect the list message submission only.  The list
will take control with its own optional 3rd party security for
distribution.

For example, I can add a new Mailing List Option:

  [X] Accept only DKIM signed submissions
      [X] From Optional Signature Policies only

This way, the domain can use a NEUTRAL (o=~) or STRONG (o=-) and the LS
will still be able to keep the integrity in check for the final
downlinks.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 23 Jan 2006 13:11:48 -0800

> sign only the headers that identify the list.
When a recipient looks at a message, they see (typically) the From:
address.  If there is a signature corresponding to this address, the
message has an Originating Address signature.  If there isn't, but there
is some other valid signature on the message, it has a third-party
signature.  It's the correspondence (or lack thereof) between the
signature address and the origin address that the user typically sees
that determines whether it's a third-party signature.

Signing the From: header is currently required, but suppose it weren't: 
It would still be significant whether or not the signature represented
the From address, and that would determine whether it was a third-party
signature or not.

-Jim

---

From: Tony Hansen <[email-masked]>
Date: Mon, 23 Jan 2006 16:19:06 -0500

I'm tempted to say: if the mailing list is going to do *anything* to the
message other than act as a simple reflector, it *must* strip out any
existing dkim signature. What it does after that is up to the mailing list.

	Tony Hansen
	[email-masked]

---

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

Hi Tony,

But presumably just adding List-ID: or similar would be ok?

Stephen.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 23 Jan 2006 17:17:17 -0500

Adding a header like that probably falls under the category of "acting
as a reflector". But of course, you can also ask, "What if there's
already a list-id header?" and "Where to add it?". (There probably won't
be such a header, of course, but it's not unheard of for lists to be
cascaded.)

	Tony Hansen
	[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 23 Jan 2006 23:31:05 +0100

> the suggestion, or else I missed it.)

When I talked about "SSP of the day" I had that in mind.  The
SSP might change.  If that would require to change many list
subscriptions it woul be messy.  Hector's proposal boils down
to "never change the SSP if it affects too many subscriptions".

                         Bye, Frank

P.S.:  Lars posted a list survey in MARID, but that was about
       PRA, <http://article.gmane.org/gmane.ietf.mxcomp/1057>

---

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

> existing dkim signature. What it does after that is up to the mailing list.

This has been my view, too, but I'm starting to see some plausible benefit in at 
least permitting co-existence.

So, I still believe that the safest policy is the old list rule we established: 
  you break it, you own it.

But recent discussions makes additional scenarios just too tantalizing to 
prohibit.  (And too complex to pursue right now.)

d/
-- 

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

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 23 Jan 2006 21:32:52 -0500

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

> to "never change the SSP if it affects too many subscriptions".

hmmmmmm, I guess that falls in line with:

    "Thou should never change your email address, once you
     subscribe or give it to anyone for that matter!"

Although its a valid point Frank, I wasn't thinking in this way.

What is more important is that the mail service XYZ checks that address
during any form of a signup process. For a LS, that's a subscription
process.

Today, you do it with a confirmation.  My input only suggest that a
Domain SSP check is added as part of this confirmation process.  That's
all.

Today, a LS system might run a monthly or some timed event to check
addresses. It might include a SSP check during this process.

Not a big deal :-)

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 23 Jan 2006 22:18:59 -0500

From: "Tony Hansen" <[email-masked]>

> I'm tempted to say: if the mailing list is going to do
> *anything* to the message other than act as a simple
> reflector, it *must* strip out any existing dkim signature.
> What it does after that is up to the mailing list.

This would make sense for certain policies. If the processor is going to
bother with 'understanding' DKIM entities, it would not make sense to
blindly strip without sound logic.

So it might suggest for a LS to offer options to just allows
subscriptions and submissions from domains with policies:

[X] Allow DKIM domains with:
    [X] NONE (no policy)
    [X] WEAK (signature optional, no third party)
    [X] NEUTRAL (signature optional, 3rd party allowed)
    [_] STRONG  (signature required, 3rd party allowed)
    ___ EXCLUSIVE (signature required, no 3rd party)
    ___ NEVER  (no mail expected)

because the above offers consistent logic to be able to strip any
signatures and distribution verifiers will not break.

If it allows a STRONG policy, then needs to do a resigning when changing
content.

EXCLUSIVE and NEVER should not apply because mail from these domains
should never gain entry into the LS network anyway (i.e. stopped at the
SMTP receiver/verifier).

If we go with a stripping concept, I think this action should to be
recorded in the headers, maybe within the DKIM results header, to track
the history of the process.

---

From: John Levine <[email-masked]>
Date: 24 Jan 2006 05:53:26 -0000

>Signing the From: header is currently required, but suppose it weren't: 

Then bad guys can take list messages and resend them with forged
return addresses and still have a valid signature.  Does anyone think
this is a good idea?

I think the way we all expect to use DKIM is that a message comes in,
we check the signature, then we look up the signing domain in some
sort of reputation system, be it a local whitelist or something
fancier, then if the reputation is good we accept the mail, if it's
bad we reject it, and if there's no reputation, we fall back and do
what we would have done otherwise.

With this model, I have a lot of trouble envisioning a scenario where
I would want list mail signed by anything other than the list.  If
there is old list software that doesn't sign and it happens to pass
signed messages, fine, but if the list software is DKIM aware at all,
I want it to sign so I can recognize list mail.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Mon, 23 Jan 2006 23:23:15 -0800

> return addresses and still have a valid signature.  Does anyone think
Since this was quoted out of context, let me emphasize that my "suppose
it weren't" was just a hypothetical for answering Wietese's question.  I
firmly believe that the From header MUST always be signed.
> what we would have done otherwise.
Agreed.
> I want it to sign so I can recognize list mail.
If the list does sufficient damage to the message that any incoming
signature is invalid, it might as well throw away the original
signature.  If it's still there, someone is likely to waste time trying
to verify it.  OTOH, if a list doesn't do that much, maybe only adds a
List-ID and similar header fields, I would be inclined to keep the
original signature.  I don't like to throw away things that may be
valid.  This attitude is also reflected in the state of my attic.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 24 Jan 2006 02:49:19 -0500

----- Original Message -----

>> I think the way we all expect to use DKIM is that a message
>> comes in, we check the signature, then we look up the signing
>> domain in some sort of reputation system, be it a local
>> whitelist or something fancier, then if the reputation is
>> good we accept the mail, if it's bad we reject it, and if
>> there's no reputation, we fall back and do what we would
>> have done otherwise.

> Agreed.

Jim,

You are kidding? Right?  Do you really agreed with this?  This is
contrary of your SSP proposal. The above is not the chartered proposal.
I hope we don't get lost into some undefined reputation concept.

IMO, DKIM will not widely adopted with a "Batteries Required" concept.
It will be nice to keep the protocol sweet and pure.

I suggest we try to keep away introducing a reputation system into the
algorithm.   It can always be added separately and independently. But as
a protocol, I don't think it will be widely accepted for a few simple
reasons - What Reputation System?  Whose Reputation System? What is the
"Fancy System?" Will it become a 3rd party central repository?  Will
there be a buy-in fee? Republican vs. Democrats?, etc.  It is going to
very hard to justify further support when we now have to begin promoting
3rd party A/R into our product lines.

If that is what you want to do, go for it, but its not the proposal and
charter - it is not DKIM nor your SSP proposal.

I would like to ask the chairs to set the record straight. If a
reputation system is part of the proposal, charter, I would like to know
this ASAP.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Jan 2006 10:29:19 +0000

Hector,

> reputation system is part of the proposal, charter, I would like to know

As I understand the charter we don't do work on reputation systems
but we can mention them in passing which is how I interpreted the
mail from John agreed to by Jim.

The charter quote is:

"To prevent this task from becoming unwieldy, several related topics are
considered out of scope for the DKIM working group. These topics
include:

* Reputation and accreditation systems. While we expect these to add
   value to what is defined by the DKIM working group, their development
   will be separate, and is out of scope for the DKIM working group.
"

Regards,
Stephen.

---

From: Mark Delany <[email-masked]>
Date: Tue, 24 Jan 2006 15:07:26 +0000

> This would make sense for certain policies. If the processor is going to

Actually I'm not sure why a list has to do anything in this case. If a
failed signature is the same as no signature, then the very action of
a mutating list has the effect of "stripping out" any existing sig. So
why impose extra work on a list? And why not let the natural course of
existing lists serendipitously "do the right thing"?

Of the big benefit is instant compliance by a huge array of
pre-existing list s/w.

I also worry about the expectation of lists looking at policy - it's
going to be many many years before a signer can expect their policy to
be looked at by a significant majority of list s/w. In the intervening
years they will be able to advertise as restrictive policy as they
like and it will mostly be disappointed at the outcome.

Mark.

---

From: [email-masked] (Wietse Venema)
Date: Tue, 24 Jan 2006 10:09:40 -0500 (EST)

> > I want it to sign so I can recognize list mail.

I see valid reasons why a mailing list submission would have a DKIM
signature over the FROM: address (and content etc.), by the domain
that controls the FROM: address. It provides assurance that the
mail actually came from that address.

I also see valid reasons why a list distributor or other forwarder
would place a DKIM signature over SOME header (and content etc.)
that identifies the mail as coming from that mailing list or other
forwarder. It provides assurance that the mail actually came through
that list or forwarder.

What is not clear to me is the benefit of a mailing list signature
that is required to vouch for the authenticity of someone elses
FROM: address.  I see this as a source of confusion with both users
and designers, and believe that this is a level of assurance that
not every mailing list or other forwarder can provide.

I am concerned that the FROM: address is becoming a conceptual
bottle neck, and would like to see a solution that allows mailing
lists and other forwarders to sign mail ("as I forwarded this")
without implied claims about the authenticity of the FROM:  address.
That is, the possibility of a mailing list etc. DKIM signature that
just authenticates the list or forwarder.

If the original submission has a DKIM signature then of course that
is great. If it doesn't, then we don't know that the mail came from
that address, period. But if it has a valid list/forwarder signature,
that can still be used to enable reputation based systems.

	Wietse

---

From: Mark Delany <[email-masked]>
Date: Tue, 24 Jan 2006 15:26:07 +0000

On Mon, Jan 23, 2006 at 11:23:15PM -0800, Jim Fenton allegedly wrote:

> signature.

How does the list know for sure? The only sure way is if it attempts
to re-verify the original signature after applying it's own
modifications.

And that assumes the original signature doesn't contain some future option
that the list doesn't know about - such as a variant l=.

So the actual rules would need to be:

 If original verifies
    and if I think I've modified badly
       and if I understand all tags in the original sig/selector
	   re-verify list output to see if original sig now fails
	   then if re-verify fails
              remove the original signature

If a list isn't fastidious about these checks then it risks removing a
"still-valid" signature because it thinks the modifications were
invalidating.

> If it's still there, someone is likely to waste time trying
> to verify it.

Is this the only benefit for this complexity? If so, does it risk
being a premature optimization?

Mark.

---

From: Mark Delany <[email-masked]>
Date: Tue, 24 Jan 2006 15:40:35 +0000

> not every mailing list or other forwarder can provide.

That raises a question about assumptions. Is the fact that a List
signature includes "whatever was in the From: " actually vouching for
the authenticity of that address, or is it merely vouching for the
fact that this is the content it received?

The former - I call transitory trust - worries me conceptually. The
latter seems safer and simpler.

> just authenticates the list or forwarder.

That's how I was viewing a List signature. It was making no claims
about the original submission apart from "these are the bits as they
arrived at the List address". If some final list recipient sees value
in the original bits, good luck to them.

> that can still be used to enable reputation based systems.

Right.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Jan 2006 07:41:22 -0800

Folks,

>> If the list does sufficient damage to the message that any incoming
...
>     and if I think I've modified badly...

Mark's note demonstrates two things to me that suggest strategic guidance for
the working group:

1. The initial technical spec needs to allow replacing one signature with 
another and it needs to allow multiple signatures.  The rule for DKIM-aware 
mediators replacing the signature probably should something like "if you break 
it, you own it".

2. The behavior of additional signers for a message may need to be relatively 
complex. Complexity requires effort to understand, before writing it into a 
standard.  So the details of this sort of behavior needs to be deferred beyond 
the current scope of the working group.

In other words, this looks like an interesting an useful topic, but one that 
does not need to be in the critical path of the current working group effort, 
except for item 1, above.

d/
-- 

Dave Crocker

---

From: [email-masked] (Wietse Venema)
Date: Tue, 24 Jan 2006 10:51:26 -0500 (EST)

> > that can still be used to enable reputation based systems.

Great. Will this also work with other (i.e. non-list) forms of
forwarding? I can see other valid reasons why a system would stamp
mail as "I handled this". In fact, any service that handles mail
in some form or another could benefit if it could provide the
assurance that it was really the provider of the service.

	Wietse

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Jan 2006 07:55:15 -0800

>>signature is invalid, it might as well throw away the original

Except for the forensic value, which is, in my experience,
valuable.

> "still-valid" signature because it thinks the modifications were

Right. Seems like an awful lot of work for <= 0 gain. The mantra
here should be "a broken signature are equivalent to no signature"
and resist this impulse to tidy up the message.

		Mike

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 24 Jan 2006 16:03:43 +0000

Dave,

Dave Crocker wrote:
> 1. The initial technical spec needs to allow replacing one signature 
> with another and it needs to allow multiple signatures.  The rule for 
> DKIM-aware mediators replacing the signature probably should something 
> like "if you break it, you own it".
> 
> 2. The behavior of additional signers for a message may need to be 
> relatively complex. Complexity requires effort to understand, before 
> writing it into a standard.  So the details of this sort of behavior 
> needs to be deferred beyond the current scope of the working group.
> 
> In other words, this looks like an interesting an useful topic, but one 
> that does not need to be in the critical path of the current working 
> group effort, except for item 1, above.

I think I like this approach - keeping stuff off the critical path
to the extent possible, but I'm a bit unclear as to where the
suggested boundary is here. Maybe the answer to this questions will
help me out:

Does #1 above include specification of *a* way for a mailing list
to add its signature to an already signed message, s.t. there is a
chance that both signatures can verify at the end-recipient's MTA.
(I can imagine that there'll be variations on how to do this, but
I assume that any such variations would be off the critical path.)

Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Jan 2006 08:09:07 -0800

> fact that this is the content it received?

Right. I've always viewed the h= (or z=) headers as being just
statements of fact: "this is what I claim to have seen". The
binding to an outside header is a function of the signature's
identity (i=), and as currently specified is whether the signer's
identity fnmatch'es the outside identity in question.

> latter seems safer and simpler.

We need something to perform the ssp binding, however. It's somewhere
between "vouching" and "content received". That is, a signer's action
should not be taken as stating that it believes that the actual
author actually submitted the message in question. Instead it is
merely stating that within its set of internal polices, it's
willing to take responsibility for that message's emanation from
that domain. Since the assertion is as good as those internal policies,
caveat receiver.

		Mike

---

From: Mark Delany <[email-masked]>
Date: Tue, 24 Jan 2006 16:42:02 +0000

> forwarding?

I can't see why not particularly if:

> [However] We need something to perform the ssp binding,

the mere presence of a signature does not imply anything more than
taking responsibility for what emanates from that domain.

If Mike is saying that explicitness is necessary, then I think that
gels with Wietse.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Tue, 24 Jan 2006 09:15:51 -0800

> I assume that any such variations would be off the critical path.)

Suggested "process" heuristic for this sort of issue:

Generate two or three different multi-signature test scenarios and make sure we 
believe/know they can work.  Keep the debate about the selection of scenarios 
limited.  They merely have to look reasonable; they don't have to be comprehensive.

Defer all other work on multiple signatures.

d/
-- 

Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Jan 2006 09:23:22 -0800

On Jan 24, 2006, at 7:07 AM, Mark Delany wrote:
>>> I'm tempted to say: if the mailing list is going to do *anything*  
>>> to the message other than act as a simple reflector, it *must*  
>>> strip out any existing dkim signature. What it does after that is  
>>> up to the mailing list.
>>
>> This would make sense for certain policies.
>
> Actually I'm not sure why a list has to do anything in this case.  
> If a failed signature is the same as no signature, then the very  
> action of a mutating list has the effect of "stripping out" any  
> existing sig. So why impose extra work on a list? And why not let  
> the natural course of existing lists serendipitously "do the right  
> thing"?

The mutations made by a list can be removed with a small effort.   
When the goal is to ensure protection from replay abuse (holding the  
recipient domain accountable for replay abuse) the dissemination of  
signatures increases this exposure.   Rudimentary changes made by  
list-server would not offer adequate protection.  When the list- 
server software is modified to at least understand DKIM signatures,  
all but the most recent MSA signature should be removed.  Any  
signature not by the list-server itself should have the signature  
portion overlaid with the verification results (even !unknown).  The  
headers included should be to protect the list-server from possible  
exploits.  As signatures use larger keys and hash algorithms, the  
overhead associated with multiple signatures would be mitigated by  
using this strategy.

> Of the big benefit is instant compliance by a huge array of pre- 
> existing list s/w.

This may not be a big benefit if replay abuse becomes problematic.

> I also worry about the expectation of lists looking at policy -  
> it's going to be many many years before a signer can expect their  
> policy to be looked at by a significant majority of list s/w. In  
> the intervening years they will be able to advertise as restrictive  
> policy as they like and it will mostly be disappointed at the outcome.

Agreed.  The time frame before using separate email policy could be  
very long.  It may be faster to include the policy directly within  
the signature, where caching would not demand additional network/time  
related overhead.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 24 Jan 2006 10:23:54 -0800

> It will be nice to keep the protocol sweet and pure.
Stephen answered this well, but I'll also assure you that I haven't
recently gone crazy.  DKIM, especially with SSP, delivers significant
value on its own, but it's also reasonable to point out the additional
benefits when it is coupled with reputation, accreditation,
[white|black]lists, or whatever.
> 3rd party A/R into our product lines.
I wasn't trying to introduce a reputation system into the algorithm. 
I'm not even sure whether reputation or accreditation will prevail when
we get to that at some point in the future.  The questions you raise are
exactly why we don't want to go down that rathole.

-Jim

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 24 Jan 2006 10:38:36 -0800 (PST)

Jim,

What I actually saw (and granted I did not had enough time to participate
and read-all posts last week) especially from Stephen's summary is 
confirmation of what I thought was true of DK is also true of DKIM -
i.e. that it can not handle mail lists well. I firmly believe that without 
being able to handle mail lists the SSP component as you call it would not 
be something that everyone wants to adapt (especially since you're 
proposing to do it all on per-domain basis and [non]use of mail lists
is largely per-user decision where as for entire domain, typically at 
least some others are using mail list). It is unfortunate that due to
how some IETF activists bypassed MASS, the situation is such that we'd 
not be able to solve the forgery issue and best you'd achieve is some 
value for use with ever more complicated spam filters.

> exactly why we don't want to go down that rathole.

If you assume that reputation & accreditation would not prevail the value
of DKIM evaporates almost entirely.

-- 
William Leibzon
Elan Networks
[email-masked]

---

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

>The mutations made by a list can be removed with a small effort.   

Sorry, Doug, but that's simply not true.  Visit Yahoo Groups, the
largest list host in the world, for a few minutes, and come back and
tell us how they would do it.  Don't forget that their business model
involves putting little tags with advertisements at the end of the
messages, and many if not most of their messages are HTML coded.

Tony encapsulated the only sensible model: you break it, you sign it.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Jan 2006 10:51:12 -0800

On Jan 24, 2006, at 10:23 AM, Jim Fenton wrote:

> Hector Santos wrote:
>>
>> I suggest we try to keep away introducing a reputation system into  
>> the algorithm.   It can always be added separately and  
>> independently. But as a protocol, I don't think it will be widely  
>> accepted for a few simple reasons - What Reputation System?  Whose  
>> Reputation System? What is the "Fancy System?" Will it become a  
>> 3rd party central repository?  Will there be a buy-in fee?  
>> Republican vs. Democrats?, etc.  It is going to very hard to  
>> justify further support when we now have to begin promoting 3rd  
>> party A/R into our product lines.
>
> I wasn't trying to introduce a reputation system into the  
> algorithm.  I'm not even sure whether reputation or accreditation  
> will prevail when we get to that at some point in the future.  The  
> questions you raise are exactly why we don't want to go down that  
> rathole.

There is a banal reality that needs to be accepted however.  Bad  
actors are capable of implementing a valid DKIM signature.  Bad  
actors are capable of obtaining an account within a large domain,  
whether through compromised systems, wireless-access points, free  
email-address accounts, subscriptions to list-servers, etc.  This  
also means the signature itself is prone to replay abuse.  There is a  
significant challenge ahead dealing with these issues without being  
blind to reasonable solutions.  While a community list offers less  
administrative effort, the same approach may apply to private efforts  
made the administrator.  There are solutions, but yes they will  
likely involve some type of reputation being applied.  There are  
companies willing to offer something like a DKIM-Adopters-List as a  
free service.  Creating a list should not be seen as a difficult  
obstacle.

DKIM does offer value beyond providing an identifier that is closer  
to the source of a possible problem.  DKIM can allow the recipient to  
recognize the source of their correspondences and know when a source  
changes.  This does not require the application of any type of  
reputation and may well depend upon out-of-band information found  
within the message as a method to safely identify the source.

Any expectation that SSP offers value is based upon the expectation  
that the recipient can visually recognize the sender by what is seen  
with the MUA.  There are many reasons to doubt that this is either  
safe or sensible.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 24 Jan 2006 10:55:42 -0800

On Jan 24, 2006, at 10:45 AM, John Levine wrote:

> largest list host in the world, for a few minutes, and come back  
> and tell us how they would do it.  Don't forget that their business  
> model involves putting little tags with advertisements at the end  
> of the messages, and many if not most of their messages are HTML  
> coded.
>

I agree with this however...

I was commenting upon the idea that valid signatures, although  
mutated by a list-server, can be recovered with some effort _by the  
bad actors_.  They of course would send messages that would undergo  
only minor transformations.  The goal would be to recover the message  
and restore functionality of the signature in order to stage replay  
attacks, taking advantage of the originating domains reputation.  
(Soon lost as a result of the signature leak.)

-Doug

---

From: John Levine <[email-masked]>
Date: 24 Jan 2006 19:40:24 -0000

>FROM: address.

It's vouching for the authenticity to the extent that it's promising
that this is the same From: address that was on the message when the
list sent it out.  It's the same promise that every DKIM signature
makes.

> without implied claims about the authenticity of the FROM: address.

As far as I know, no DKIM signature, from anyone, ever makes any
claims about the authenticity of the From: address.  A DKIM signature
is a statement from the signing domain that "this is mine", not "this
is real".

Perhaps some grandson-of-SSP will let signers publish assertions
about the semantics of their signatures, but that is vastly beyond
the scope of anything we're considering now.

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Tue, 24 Jan 2006 12:09:20 -0800

>If Mike is saying that explicitness is necessary, then I think that
I'm sorry Mark, this is a bit too terse for my semantic analyzer.  -base 
just says
"this is what I claim passed through me". -ssp requires a binding 
between the
From: address (sender:? listId:?) and the i= to validate the policy binding,
if any.

Maybe it's just that I'm confused about what's being asked here.

       Mike

---

From: Jim Fenton <[email-masked]>
Date: Tue, 24 Jan 2006 16:13:24 -0800

william(at)elan.net wrote:
> i.e. that it can not handle mail lists well. I firmly believe that
> without being able to handle mail lists the SSP component as you call
> it would not be something that everyone wants to adapt (especially
> since you're proposing to do it all on per-domain basis and [non]use
> of mail lists
"Adopting" SSP [I assume you mean adopt rather than adapt] is different
from publishing a very restrictive SSP record.  While a lot of domains
might want to publish policies prohibiting third-party signing and the
like, only a small number of domains really use email in a manner that
permits this.  It's still worthwhile to have for those originators that
don't use mailing lists.

In the current -ssp draft, there is an option to extend SSP to
individual addresses.  It has significant overhead, however, and I'm
uncertain as to whether it's a sensible tradeoff between overhead and
functionality.

I don't know how "bypassing MASS" prevents us from solving technical
issues with DKIM.  If you have a specific suggestion (preferably one
that is within the group charter), please propose it.
> of DKIM evaporates almost entirely.
I think this depends on what you think the value is.

-Jim

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 24 Jan 2006 16:22:47 -0800 (PST)

> that is within the group charter), please propose it.

I do know how to solve this by other technical means. However, I can
not make a suggestion that would be within group's charter and once 
decisions such as charter are made I actually do abide by the rules
even if I disagree. All that is why I said it was a bad idea to bypass 
MASS for such a restrictive work.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 24 Jan 2006 17:18:28 -0800

> existing lists serendipitously "do the right thing"?
This makes sense to me.  The main reason I can think of for removing a
previous signature is the effort involved in trying to verify it.  But
that's just an optimization.

-Jim

---

From: Steve Atkins <[email-masked]>
Date: Tue, 24 Jan 2006 17:25:41 -0800

On Jan 24, 2006, at 5:18 PM, Jim Fenton wrote:

>> If a

It's, ah, not unlikely that at least some recipient MTAs will  
consider an
invalid DKIM signature as evidence that the email is spam, a virus or
mind control cooties from the little orange martians. That's likely to
reduce deliverability for messages with invalid signatures, or anything
that even looks vaguely like them.

So... regardless of what is decided here I expect some MLMs will
strip out incoming signatures, if doing so will increase their  
deliverability
even marginally. That doesn't mean you should mandate doing so,
of course, but don't assume that remailers of various types won't do
so either.

Cheers,
   Steve

---

From: Jim Fenton <[email-masked]>
Date: Tue, 24 Jan 2006 17:32:41 -0800

There's an interesting semantic issue here:

> not every mailing list or other forwarder can provide.
There are (at least) two ways to view the choice of header fields to sign:

1. The signer takes responsibility for the signed header fields, and no
others.

2. The signer takes responsibility for the message as a whole; the
selection of signed header fields represents those which the signer
considers sufficient to consider the message signed.

I subscribe to view #2.  It is considerably simpler to just be able to
say "the message is signed" or not.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Tue, 24 Jan 2006 20:43:26 -0800

Steve Atkins wrote:
> It's, ah, not unlikely that at least some recipient MTAs will consider an
This goes back to the topic of how much we need to accommodate verifiers
that interpret things wrong.  Messages will be signed in order to
increase their deliverability.  If verifiers behave in this way, people
will be reluctant to sign messages at all because there will be a
possibility that the signature will impede deliverability in the event
that something enroute (e.g., SpamAssassin with certain settings)
"breaks" the signature.
> of course, but don't assume that remailers of various types won't do
I would much rather put whatever language is necessary in the
specifications and/or overview document to guide implementers to
interpret signatures, and in particular broken ones, appropriately.

Besides, everyone knows Martians are green, not orange. 
http://www.imdb.com/title/tt0058548/

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 25 Jan 2006 07:39:44 -0500

----- Original Message -----

> This goes back to the topic of how much we need to accommodate
> verifiers that interpret things wrong.  Messages will be signed
> in order to increase their deliverability.  If verifiers behave in
> this way, people will be reluctant to sign messages at all because
> there will be a possibility that the signature will impede
> deliverability in the event that something enroute (e.g.,
> SpamAssassin with certain settings) "breaks" the signature.

Jim,

Please don't think the worst of me with any of this. I'm just expressing
my technical opinion on the matter.

I think you are underestimating the flip side - receivers won't bother
with implementing DKIM verification.  DKIM Signatures - valid, broken or
otherwise, without a concept that is essentially a "permission or
authorization to sign verification" concept, has little to no value.

We need solid good reason why we should add the check for DKIM signed
messages.  A signed message is not enough.

Just look at your own broken DKIM signatures in the IETF-DKIM forum.

Explain to me why this is an acceptable message over lets say a bad
actor who has learned that its par for the course and will simulate and
emulate your broken message?  Further, he doesn't need your private key.
He just needs to fake the signature.

How can I protect you?

The only reason IETF-DKIM messages is allowed in my system is because it
white listed.

But can I use a broken Jim Fenton DKIM signed messages as a mouse trap
here that are not being sent by this list?

You got to give me solid, logical and deterministic reasons why we
should even bother looking for DKIM signatures - valid or not.

Here is one simple implementation of a Lite Weight DKIM/SSP mouse trap:

Step 1) Message arrives.

Step 2) It goes thru normal/established testing, and
        its indeterminate. Move to next state.

Step 3) DATA stage is reached. Message is transfered, no
        response yet.

Step 4) Hook is run to check for SSP

  If domain SSP says NEVER, issue 5xx or 4xx rejection response.

  If domain SSP says EXCLUSIVE:
     If No DKIM-signature, issue 5xx or 4xx rejection response.
     If Sender != From , issue 5xx or 4xx rejection response.

  If domain SSP does't exist (NONE), accept message, issue
  positive 250 response.

  [Place Holder for additional Logic of relaxed policies]

The point is, I don't need any DKIM signature verification overhead. 1
DNS Policy Lookup. No need get the public key.   The above would be 100%
compatible with the draft SSP specification.

The problem is not so much relaxed policies and the talk that broken
signatures are ok, but that relaxed attitude blocking the groundwork to
minimize the issue enough that we might as well leave the place holder
above empty. Why bother trying to verify the signature?

---

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

Hector Santos wrote:
 
> I think you are underestimating the flip side - receivers
> won't bother with implementing DKIM verification.  DKIM
> Signatures - valid, broken or otherwise, without a concept
> that is essentially a "permission or authorization to sign
> verification" concept, has little to no value.

+1   A bit like a signed timestamp line (?)  Certainly nice to
have a single format for all signing MTAs, and to aggregate
them into sets of signing MTAs belonging to the same signing
MON or mediator.

For the MRN that might be faster and is probably much more
reliable than to analyze the timestamp lines.  But a chance
to reject some "bad" mails directly would be better.

> You got to give me solid, logical and deterministic reasons
> why we should even bother looking for DKIM signatures - valid
> or not.

Those "sets of signing MTAs belonging to the same signing MON"
are less granular than "sending IPs" as used for DNSBLs.  That
could be an advantage if you have your own local "reputation"
database.  E.g. if you get a mail from Jim signed by Cisco you
could say "Cisco mails are often good".  If you get a similar
mail signed by #####groups that might be different... <beg>

> Why bother trying to verify the signature?

Feedback loop with a scoring system based on reputation ?  Bye

---

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

Douglas Otis wrote:

>> I also worry about the expectation of lists looking at
>> policy - it's going to be many many years before a signer
>> can expect their policy to be looked at by a significant
>> majority of list s/w. In the intervening years they will
>> be able to advertise as restrictive policy as they like
>> and it will mostly be disappointed at the outcome.
 
> Agreed.  The time frame before using separate email policy
> could be very long.  It may be faster to include the policy
> directly within the signature, where caching would not demand
> additional network/time related overhead.

Good idea for valid signatures.  For the "closed" policies I'd
guess that SPF would offer an accelerator.  Receivers checking
SPF won't need to lookup any SSP separately.  Scott proposed a
scheme where they could simply ignore the SPF policy if they
found a promise that there MUST be a valid DKIM signature:  If
that's not the case they reject the mail at the end of DATA.

                                Bye, Frank

---

From: Douglas Otis <[email-masked]>
Date: Wed, 25 Jan 2006 15:03:25 -0800

On Jan 25, 2006, at 4:39 AM, Hector Santos wrote:
>
> I think you are underestimating the flip side - receivers won't  
> bother with implementing DKIM verification.  DKIM Signatures -  
> valid, broken or otherwise, without a concept that is essentially a  
> "permission or authorization to sign verification" concept, has  
> little to no value.

This overlooks the value that a verified signature offers with  
respect to indicating the true source of the message.  Although this  
may not be exciting news for an MTA operator, this could be a highly  
valuable feature for the recipient when next generation MUAs allow  
recipients to register important sources, such as messages from their  
bank or broker.  SSP is not needed for this type of approach to be  
both _safe_ and effective.

> We need solid good reason why we should add the check for DKIM  
> signed messages.  A signed message is not enough.

A signed message is better than not having a signed message.  The  
message signature tells the recipient where the message originated.

> Just look at your own broken DKIM signatures in the IETF-DKIM forum.

Sending only to domains on an DKIM-Adopters-List would remedy this  
concern.  This would ensure signatures are _not_ damaged in transit.

> actor who has learned that its par for the course and will simulate  
> and emulate your broken message?  Further, he doesn't need your  
> private key. He just needs to fake the signature.

A faked or broken signature would never misidentify the source of the  
message by a next generation MUA. : )

> How can I protect you?

Filtering for phishing attempts _must not_ rely upon the From email- 
address being spoofed.  Content filtering needs to compare embedded  
links and address information against the DKIM signature.  The From  
address alone does not provide a _safe_ basis for accepting a message  
based upon compliance with some policy.  A filter application will  
obtain timely, critical identifiers through empirical sources.  A  
high overhead searching for, and the limited utility of the SSP  
record will likely mean there is too little value checking for the  
existence of policy a record.  There is always value checking a  
signature, _especially_ when there is care taken with respect to  
where signed messages are sent.

> The only reason IETF-DKIM messages is allowed in my system is  
> because it white listed.

An DKIM-Adopters-List would preclude the need for this effort.

> But can I use a broken Jim Fenton DKIM signed messages as a mouse  
> trap here that are not being sent by this list?

Yes, when the DKIM-Adopters-List is being employed by the sender.

> should even bother looking for DKIM signatures - valid or not.

With the use of the DKIM-Adopters-List, all DKIM signatures should be  
valid, or they are suspect and _should_ be rejected.  This behavior  
will allow the construction of private DKIM-Adopters-Lists.

> Here is one simple implementation of a Lite Weight DKIM/SSP mouse  

This dog won't hunt.  Bad actors are just as able to sign messages.   
There is no reason to expect the recipient is able to recognize good  
actors from bad actors by what is displayed by the MUA.  Assuming  
there is a next generation MUA, there will still not be a need for  
any SSP record.

> The point is, I don't need any DKIM signature verification  
> overhead. 1 DNS Policy Lookup.

This DNS Policy Lookup will be across several locations for each and  
every message signed by a different domain or not signed at all.  The  
Policy lookup represents perhaps the greatest overhead in this  
scheme.  All those email-address domains without a policy record also  
means there will not be a record contained within the cache to  
mitigate this effort the next time a message comes from that domain.   
It is not one DNS Policy Lookup, but perhaps hundreds or thousands  
before a useful closed policy is discovered.

> No need get the public key.

Getting and using the public key would represent a small component of  
that overall effort.  Much less than that associated with the SSP  
record.

-Doug

---

From: <[email-masked]>
Date: Wed, 25 Jan 2006 18:39:23 -0500

Hector
> should even bother looking for DKIM signatures - valid or not.
right now for inbound messages from yahoo.com I check to see if there is a dkim= string, if so sent off for further processing, if not toss it :-)
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Douglas Otis
Sent: Wed 1/25/2006 6:03 PM
To: Hector Santos
Cc: [email-masked]
Subject: Re: [ietf-dkim] How mailing lists mutate messages

-Doug

---

From: Mark Delany <[email-masked]>
Date: Thu, 26 Jan 2006 20:22:01 +0000

> I'm sorry Mark, this is a bit too terse for my semantic analyzer.

I take that as a complement on this list ...

> -base 

Right. So the question is, can a signature be constructed such that it
doesn't interact with SSP to infer a binding above and beyond "I claim
it passed through me"?

Mark.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Jan 2006 13:48:56 -0800

On Jan 26, 2006, at 12:22 PM, Mark Delany wrote:

>>> the mere presence of a signature does not imply anything more  
>>> than taking responsibility for what emanates from that domain.
>>>
>>> If Mike is saying that explicitness is necessary, then I think  
>>> that gels with Wietse.
>>
>> just says "this is what I claim passed through me". -ssp requires  
>> a binding between the From: address (sender:? listId:?) and the i=  
>> to validate the policy binding, if any.
>>
> Right. So the question is, can a signature be constructed such that  
> it doesn't interact with SSP to infer a binding above and beyond "I  
> claim it passed through me"?

This idea has been explored in the dkim-options draft, although  
perhaps not well explained.  This draft includes a 'w' parameter  
within the signature.  Perhaps this could be described as the "What  
role or verification semaphore."

http://www.ietf.org/internet-drafts/draft-otis-dkim-options-00.txt

The signature should allow expressions beyond "it passed through  
me".  The signature could indicate the purported role of the signer,  
such as a signature on behalf of the MSA, MUA, mediator, or MDA.  The  
MSA/MUA could be differentiated by an indication via the key that the  
signature is less trustworthy, which reduces the list to just MSA,  
mediator, or MDA.  Use of the MDA role for the signature would be to  
ensure messages are not tampered with while en-route within the  
receiving AdmD, especially with a practice that overlays the  
signature with results.  The overlay could be a means to prevent  
anyone within the receiving domain staging abusive replay attacks  
against those sending messages to the domain, or the domain itself,  
as the MDA signature would never be accepted elsewhere.

The signature should also be able to indicate what had been verified  
within the message.  Currently, the 'i=' parameter provides a means  
to express a validation of some email-addresses only within the  
signing domain.  If an opaque-identifier were used and verified,  
there should also be a standardize way of expressing that this non- 
email-address identifier has been verified, which can help resolve  
email sources within a domain in a manner independent of an email- 
address.

Imagine a large provider signs any and all messages.  Injecting a  
Sender header alters the appearance of the email.  An essential goal  
of DKIM is to not alter the appearance.  Sender header may also be in  
conflict when this header is already included within the message  
being sent.  To allow the identification of unique sources with the  
domain, the provider may instead include an account identifier within  
the signature.  The account identifier can be obtained from the  
authentication at the MSA when accepting the message.

This account identifier is constructed in a manner to allow a  
"redemption" table to be prefixed above the account identifier (O- 
ID).  This prefixed table value allows the revocation of messages  
from a specific account, while allowing an easy means to re-enable  
new messages from the account.  This would not depend upon the use of  
an email-address, which creates additional exposure to email abuse,  
or a greater loss of privacy.

The same 'w' semaphore mechanism can replace the 'i=' parameter by  
associating a header with a signing role.  The MSA would always be  
associated with the From, but never would the mediator.  Perhaps the  
mediator would always associate with the Resent-* header.  Specific  
codes could be created for specific headers.  The signing semaphore  
can indicate more than just roles, but also verification assurances.  
These assurances may be the entire email-address is always verified  
(w=d), just the domain of the email-address is always verified (w=a),  
or that any email-address for this domain is always signed and  
verified (w=b), or that this email-address is always signed and  
verified (w=n).

If there is a policy either obtained or cached for a specific email- 
address, it should differentiate between the source of the message  
based upon the role of the signature.  The current concept of the SSP  
precludes making this differentiation, but a next generation of MUA  
should have no difficulty being able to treat role identities  
separately without degrading safety.  Perhaps there could be  
signaling semaphores that indicate a mediator is not allowed for a  
scope of email addresses, as an interim solution.  This was not  
explored in the dkim-option draft.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Thu, 26 Jan 2006 14:32:55 -0800 (PST)

> doesn't interact with SSP to infer a binding above and beyond "I claim

Make 'i' optional.

My preference however is to have field in signature that specifies
what type of email parameter the signature is associated with (i.e.
see 'id' segment of metasignatures).

---

From: Jim Fenton <[email-masked]>
Date: Thu, 26 Jan 2006 16:19:54 -0800

> my technical opinion on the matter.
Don't worry about that -- I'm interested in what you have to say, even
(and perhaps especially) if we disagree.
> He just needs to fake the signature.
I agree; any "verifier" that places extra acceptance-value on a message
just because it looks like it's signed (but doesn't actually verify the
signature) is doing something worse than someone who just ignores DKIM
outright.  The reason is that the pseudo-verifier is encouraging others
to spoof DKIM signatures.  DKIM can handle spoofed signatures, but it's
just not something we want anyone to encourage since bogus signatures
take (a little) time to verify.
> here that are not being sent by this list?
I'm not sure what you mean by a "mouse trap".  You shouldn't consider
messages with an invalid signature any differently from messages lacking
the invalid signature, if that's what you mean.
>      If Sender != From , issue 5xx or 4xx rejection response.
By "Sender", do you mean "Signer"?  (and I presume you would check the
signing address of all the signatures on the message).

This is one set of possible verifier policies; SSP really gives guidance
on what to consider "suspicious" which is intentionally vague and up to
verifier/recipient interpretation.  [Although a couple of places in -ssp
section 5 it does talk about message acceptance, and I will propose to
change that.]  It also seems to assume that the verifier is the MX host
for the domain; if it's a later hop, you will probably not want to 4xx a
message because it shifts the burden onto yourself.
> compatible with the draft SSP specification.
Yes, it is.  I have to say that I am a little uncomfortable with the
idea that a message might get a 5xx if it had no signature but not if it
had an invalid one (presumably they get a bounce in that case?). 
Perhaps we need some better wording in the specs about that.
> above empty. Why bother trying to verify the signature?
Not verifying the signature is one of those things that you can probably
get away with if you're the only one that does it, but something that
will be very quickly exploited if you're not.  While it's very hard to
dictate (and in some cases, even to determine) what verifiers do, I
expect that any implementer that doesn't actually do the verification
will quickly lose customers.

Thanks; you have given me some good things to think about.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 26 Jan 2006 16:59:24 -0800

>> doesn't interact with SSP to infer a binding above and beyond "I claim
'i' is optional, but takes the value @d if it is missing.
> see 'id' segment of metasignatures).
If we know this, presumably one could tell, for example, whether a
signature came from a mailing list.  But it's the signer's assertion
what their role is:  one might imagine setting up a rule, "I'll accept
any messages re-signed by mailing lists."  So the Bad Actors will just
start adding a few more headers, and all of a sudden you're getting lots
of mail from the [email-masked] mailing list, with
messages from "people" talking about what great deals they got.

Since there's no way to know what the role of the signer really is, it's
not a useful piece of information.  What is useful is who the signer is,
and then the verifier or recipient might recognize it:  Oh, it's signed
by mipassoc.org, which gives the responsible address as
[email-masked].  I know that's a mailing list.

-Jim

---

From: John Levine <[email-masked]>
Date: 27 Jan 2006 01:55:44 -0000

>claim it passed through me"?

I'm increasingly getting the impression that we don't really
understand the semantics of SSP.  If a domain uses SSP to say that it
signs everything, and a message from that domain has both the domain's
signature and someone else's, is that OK?  I can easily imagine
interpretations of SSP that would go either way.

R's,
John

PS: "imply"

---

From: Douglas Otis <[email-masked]>
Date: Thu, 26 Jan 2006 18:52:24 -0800

On Jan 26, 2006, at 4:59 PM, Jim Fenton wrote:
>>> Right. So the question is, can a signature be constructed such  
>>> that it doesn't interact with SSP to infer a binding above and  
>>> beyond "I claim it passed through me"?
>>
>> Make 'i' optional.
>
>> what type of email parameter the signature is associated with  
>> (i.e. see 'id' segment of metasignatures).
>
> signature came from a mailing list.  But it's the signer's  
> assertion what their role is:  one might imagine setting up a rule,  
> "I'll accept any messages re-signed by mailing lists."  So the Bad  
> Actors will just start adding a few more headers, and all of a  
> sudden you're getting lots of mail from the unbelievable- 
> [email-masked] mailing list, with messages from "people" talking  
> about what great deals they got.

This overlooks an important application of the DKIM signature.  An  
approach using DKIM can ensure look-alike domains, use of unicode,  
ACE labels, or display-name only headers will _never_ be a problem.   
This would be the use the DKIM signature to both register and  
recognize the source of a message.  Simple "out-of-band" methods can  
ensure the source of the message, such as including pass-phrases or  
pictures selected when subscribing to a service.  Once registered,  
these messages can be marked to signify it originates from a  
recognized registered source.

When there is an apparent conflict, the recipient should be warned.   
Their registration may need to have the source of the message  
ignored, merged with or replace the existing registration, or perhaps  
blocked as a spoof.  This conflict notification would be a nuisance  
without the role of the signer also included.  When the Mediator role  
is noted, the next generation MUA would be able to ignore innocuous  
Mediator conflicts with an MSA source, the likely case.

The lack of a registered marking on a message that purports to be  
from a registered source would alert the user as well, hence this  
would be highly spoof resistant.  This approach allows the safe and  
painless use of Mediator related services.  The source of the message  
could also indicate that a Mediator role is not permitted, but this  
was not covered in the dkim-options draft.  It seemed better to  
assume prohibiting the use of Mediator sources will not be required,  
following the introduction of the next generation MUAs, or plug-ins  
and pre-filters for legacy MUAs.  By the way,  signature overlays and  
the MDA role will be needed to accommodate markings made by pre- 
filters to support legacy MUAs. : )

> Since there's no way to know what the role of the signer really is,  
> it's not a useful piece of information.  What is useful is who the  
> signer is, and then the verifier or recipient might recognize it:   
> Oh, it's signed by mipassoc.org, which gives the responsible  
> address as [email-masked].  I know that's a mailing  
> list.

You don't need to know the true role of the signature.  As with  
virtually everything within a DKIM signed message, beyond the domain  
of the signature, nothing should be trusted.  With that in mind,  
being able to differentiate between an MSA that purports to be that  
of your bank, and those on a financial list-server posted to by  
employees of your bank, allows you to understand these as coming from  
different sources.  This differentiation allows the next generation  
MUA or pre-filters to ignore harmless the role based conflicts.  All  
those important messages will be marked as registered with far less  
interaction.

Phishing protection requires a pre-filter that must _not_ assume that  
the From address is being spoofed.  This is the assumption being made  
with SSP.  That assumption represents a serious flaw in the  
protection being sought.

It seems rather safe to assume that with the aid of just the base  
DKIM signature, intelligent pre-filters and next generation MUAs will  
remove most spoofing concerns.  There will be extremely little  
administration needed, as there is no complex matrix tables returning  
multi-level acceptance results, or email-address domain owners  
wondering where their email went.  Recognizing the source of a  
message provides yes or no results for the recipient.  Remember, the  
majority of recipients only see the display-name.  When erecting a  
barrier, be prepared to handle exploits using a different avenue.   
Currently, main street is bustling with blind users expecting  
protection.  With the SSP approach, they will not see what hit  
them.  : )

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 00:20:19 -0500

----- Original Message -----
From: <[email-masked]>

> Right now for inbound messages from yahoo.com I check to see
> if there is a dkim= string, if so sent off for further processing,
> if not toss it :-)

So what you are saying is that YAHOO.COM has a "SSP" that says a
signature is required, STRONG or EXCLUSIVE?  I haven't checked. Do they?
That would be a wonderful event in the annals of computing history! <g>

But following the SSP protocol, we can't do this unless the SSP says:

   o=-  STRONG  (signature required, 3rd party allowed)
   o=!  EXCLUSIVE (signature required, no 3rd party)

---

From: Graham Murray <[email-masked]>
Date: Fri, 27 Jan 2006 07:11:59 +0000

> That would be a wonderful event in the annals of computing history! <g>

I do not think that Yahoo 'does' DKIM at all. They are using DK. In my
naivety I thought that DKIM was supposed to be the next step and
replacement for DK, so I wonder why Yahoo et al are still only using
the older DK.
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: "william(at)elan.net" <[email-masked]>
Date: Fri, 27 Jan 2006 03:38:35 -0800 (PST)

> 'i' is optional, but takes the value @d if it is missing.

Then define it so that it could have empty value ("i=") that would
mean 3rd party signer, not associated with "from".

> signature came from a mailing list.

I explained it before - the way to it is for 3rd party is to associate
signature with signing host itself. For mail list this could also be 
directly associated with listid (per RFC2919 list-id has similar format
to hostname). The result is that you know for sure that email message
came from mail list (even if it has afterward been forwarded) and can 
make the reputation decision based on how well the mail list is run
(i.e. its clean and uses good anti-spam and anti-forger policies, etc.)

> But it's the signer's assertion what their role is:  one might imagine 
> setting up a rule, "I'll accept any messages re-signed by mailing 
> lists."  So the Bad Actors will just start adding a few more headers, 
> and all of a sudden you're getting lots of mail from the 
> [email-masked] mailing list, with

See above.

> it's not a useful piece of information.

You're wrong - the information is still useful. If we take your
view that additional info coming directly from me is of no use,
then fields like Received (and in fact any trace fields) are also
of no use, since I just claim that. Similarly in fact for most
origin fields, like say "reply-to".

> What is useful is who the signer is, and then the verifier or
> recipient might recognize it:  Oh, it's signed by mipassoc.org,
> which gives the responsible address as [email-masked]. 
> I know that's a mailing list.

For recipient, its easier to make association of the address with
mail list when signature explains that its a mail list. This makes 
processing of this data on recipient end more streamlined. This
does not change the fact that if somebody claims its a mail list
and recipient can not verify from its known list of mail lists
(known may include checking with external accreditation/reputation
authority), this fact is not going to be accepted.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 27 Jan 2006 14:21:56 +0100

John Levine wrote:
 
> understand the semantics of SSP.  If a domain uses SSP to say
> that it signs everything, and a message from that domain has
> both the domain's signature and someone else's, is that OK?

> I can easily imagine interpretations of SSP that would go
> either way.

I'd guess OK.  The problem is the first figure in Jim's draft,
it doesn't directly indicate that mediators have to check the
SSP before they add their signature.

Indirectly it is clear, Jim's figure is actually for the case
MON -> MRN.  For a mediator = ( MRN + MON ) the figure has to
be doubled:  MON -> ( MRN + MON ) -> MRN.

So in the case of a mediator it's _first_ "ceck signature", if
valid check SSP, and _then_ afterwards maybe add own signature.

For the WEAK idea it needs to "check SSP" even if there is no
(valid) signature.
                           Bye, Frank

---

From: Mark Delany <[email-masked]>
Date: Fri, 27 Jan 2006 14:22:38 +0000

> replacement for DK, so I wonder why Yahoo et al are still only using

You are right that DKIM is the next step beyond DK.

Since so many folk track what we do, and adopt as we adopt, we think
it would be irresponsible to switch to DKIM as it is today, then DKIM
as it is in 3 months and DKIM as it is in 6 months, etc. Jerking
around the many thousands of domains that have adopted DK and
presumably will adopt DKIM would likely cause more harm than good.

In short, we need to be sure that the WG is close to a consensus on
what DKIM is, then the plan is to switch with a likely large overlap
period. In fact, this is a matter we've discussed with some of the
high value DK senders, and they helped shaped this strategy.

The other more selfish reason is that we're talking a lot of
infrastructure here, testing and deploying is a non-trivial exercise
that one does not want to repeat simply because a bit was flipped in,
say, the signature specification.

Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 09:35:32 -0500

----- Original Message -----

>> Right. So the question is, can a signature be constructed
>> such that it doesn't interact with SSP to infer a binding
>> above and beyond "I claim it passed through me"?
>
> I'm increasingly getting the impression that we don't
> really understand the semantics of SSP.  If a domain uses
> SSP to say that it signs everything, and a message from that
> domain has both the domain's signature and someone else's, is
> that OK?  I can easily imagine interpretations of SSP that
> would go either way.

Here is the current proposed policies:

         NONE (no policy)
    o=?  WEAK (signature optional, no third party)
    o=~  NEUTRAL (signature optional, 3rd party allowed)
    o=-  STRONG  (signature required, 3rd party allowed)
    o=!  EXCLUSIVE (signature required, no 3rd party)
    o=.  NEVER  (no mail expected)
    o=^  USER

Note: WEAK proposed by Arvel.

For the given above condition, the DKIM VERIFER would only allow it if
the domain declared a STRONG (o=-) policy.

In addition, the SECOND signer (someone else's) or 3rd party signer
(3PS) was allowed to sign it as a 3rd party only because the Original
Address (OA) domain allowed it.

So the 3PS needs to check the OA policy as well if it wishes to resign
it, otherwise it will fail at the final DKIM verification.

This chart should help see the process.

Table 1.0 - DKIM Verification States illustrates all possible
            outcomes for signature verification against SSP.

            +------------------------------------------------------+
            |            Sender Signing Policy Result              |
+-----------+----------------------------------------------+-------|
| result    |  WEAK  | NEUTRAL | STRONG  | EXCLU  | NEVER  | NONE  |
| verify    |   OPT  | OPT/3PS | REQ/3PS |  REQ   |        |       |
+-----------+--------+---------+---------+--------+--------+-------|
| NONE      | accept | accept  | reject  | reject | reject | accept|
|-----------+--------+---------+---------+--------+--------+-------|
| PASS      | accept | accept  | accept  | accept | reject | warn  |
|-----------+--------+---------+---------+--------+--------+-------|
| PASS 3PS  | reject | warn    | accept  | reject | reject | warn  |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL      | warn   | warn    | warn    | warn   | reject | warn  |
|-----------+--------+---------+---------+--------+--------+-------|
| FAIL 3PS  | reject | warn    | warn    | reject | reject | warn  |
+------------------------------------------------------------------+

Note, the above is not a suggestion on how a system should behave but
rather showing the logical conditions that must exist when the protocol
is consistently followed 100%.

As you can see, there are some hard accept/reject deterministics
conditions that can be followed both automated signers and verifiers.
There are the ACCEPTS and REJECTS.

There are also the indeterminates too, which I labeled as WARN.

Example readings of table:

Never Column. The NEVER column must be all rejects.

Exclusive column.  The old time that should be a ACCEPT is with a VALID
(PASS) signature from the original domain. Any attempt by 3rd party
Signer (3PS) PASS or FAIL should be a REJECT.   If the verify fails,
then is labeled WARN because we don't know why it failed.   I believe
others has suggested that should be a REJECT, I agree too.

---

From: "John R Levine" <[email-masked]>
Date: 27 Jan 2006 09:41:38 -0500

> > really understand the semantics of SSP.

> Here is the current proposed policies: ...

>     o=!  EXCLUSIVE (signature required, no 3rd party)

Well, OK.  if a message has both a signature from the From: domain and
one from someone else, does that pass?  Why or why not?

I'm not proposing we solve this here, just that we note that SSP is a can
of worms that we must carefully keep out of the path of the basic
signature work.

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

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 10:04:13 -0500

----- Original Message -----
From: "John R Levine" <[email-masked]>
Subject: Re: [ietf-dkim] Attempted summary, SSP again

> one from someone else, does that pass?  Why or why not?

For the EXCLUSIVE policy?  Following SSP, it would be a REJECT because
the policy says no 3PS should exist.   If it does, then it should be
given the evil eye.

> I'm not proposing we solve this here, just that we note that SSP
> is a can of worms that we must carefully keep out of the path of
> the basic signature work.

I understand what you are saying, but it is what it is. That is what the
DKIM/SSP drafts defines. It is already "solved" per se.  All I am showed
are the effective boundary conditions. The protocol is well defined and
the only way to get maximum security benefits is to make sure are
parties consistently follow it.  Any deviation from it and the protocol
breaks down with loop holes.

I think its doable and both logical and technical merits.  Whether its
feasible, practical to have both signer and verifier policy
verification, that's another issue.  But that is what is required to
make what is proposed work.

It is up to us to decide if DKIM/SSP is ok. But if we are going with
this stuff, following SSP is the only way we can make any sense of the
signatures.  Anyone can sign anything.  But are you authorize to sign
it?

In my view, without SSP, the only signature policy is a EXCLUSIVE one.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jan 2006 07:07:57 -0800

> one from someone else, does that pass?  Why or why not?

I've always interpreted this as it should pass. What would be
the reason that it shouldn't? That the other signature gave it
cooties?

		Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 10:24:13 -0500

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "John R Levine" <[email-masked]>

> the reason that it shouldn't? That the other signature gave it

Which one of the following processes is more optimal from a SMTP/DNS,
CPU processing perspective:

ProcessA() - SSP Lookup only for unsigned mail.

    - Message Arrives
    - Verification
        - Perform DNS look to get Public Key
        - Perform Hashing
        - Signature is Valid
    - OA SSP checking - NONE because it is a valid signature
    - Message Accepted

ProcessB() - SSP lookup

    - Message Arrives
    - OA SSP Policy lookup
       - EXCLUSIVE
           - Two Signers found --> REJECT

I would think ProcessB() is more ideal, more efficient and 100% DKIM/SSP
compatible, and more importantly with a rejection result that is mostly
likely to be more correct than ProcessA() acceptance of an OA domain
policy voilation.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jan 2006 07:26:41 -0800

> the policy says no 3PS should exist.   If it does, then it should be

That's not what it says. It says:

      "!  All mail from the entity is signed; Third-Party signatures
          SHOULD NOT be accepted"

In the context, it means that it requires a first party signature.
It should probably be more explicit on this point.

		Mike

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jan 2006 07:33:17 -0800

> likely to be more correct than ProcessA() acceptance of an OA domain

This is not an issue of efficiency, it's an issue of getting the
semantics correct. Your interpretation is not correct. And if I
had some caffeine, I could probably construct interesting DOS
attacks against your semantics for the first party.

		Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 10:43:06 -0500

----- Original Message -----

>> For the EXCLUSIVE policy?  Following SSP, it would be a
>> REJECT because the policy says no 3PS should exist.
>
>       "!  All mail from the entity is signed; Third-Party
>           signatures SHOULD NOT be accepted"
>

In the context of the Levine's question,

   Levine:
   "if a message has both a signature from the From: domain
    and one from someone else, does that pass?  Why or why not?"

Following your SSP draft description as posted above, this would be an
unaccepted condition.

What is the difference?

---

From: Michael Thomas <[email-masked]>
Date: Fri, 27 Jan 2006 07:51:39 -0800

> Following your SSP draft description as posted above, this would be an

The second clause is only trying to make explicit that a third
party signatures is not an acceptible substitute for a first
party signature from that domain. Which it isn't. You're making
a leap that it should also cast a shadow on the first party
signature. The text definitely does not say that, and it was
not the intent since we were purposefully dancing around the
multiple signature question.

If it has a valid first party signature, it passes. If it doesn't,
it doesn't.

		Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 11:03:45 -0500

----- Original Message -----

> a leap that it should also cast a shadow on the first party

I made no such leap. You are talking semantics.

> The text definitely does not say that, and it was not
> the intent since we were purposefully dancing around the

And if has a 3rd party signature is present for the O=! policy, then is
is REJECTED whether the DRAFT says it or not. If your intepretation is
to say it acceptable message, then we have a BROKEN PROTOCOL and you
guys better get this all straight before moving any further.

PS: I have a few bags of Cafe Bustelo that I can send you if you like?
Could help you with your DOS attack project. <g>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Jan 2006 16:16:41 +0000

Folks,

> I made no such leap. You are talking semantics.

While its an interesting question, SSP is two steps further along
from where-we-are-now:

0. Right now we should be focusing on the threats draft.
1. Then on the base protocol.
2. And *then* on details like this.

I'd love to see some more review of the threats document. It can't
be that perfect can it?

Stephen.

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 27 Jan 2006 17:38:18 +0100

> I would think ProcessB() is more ideal, more efficient and
> 100% DKIM/SSP compatible, and more importantly with a
> rejection result that is mostly likely to be more correct
> than ProcessA() acceptance of an OA domain policy voilation.

IBTD for your "Two Signers found --> REJECT" shortcut.  It's
enough to reject it if no signature matches the SSP domain.

BUT I think anything else you said here is correct, and this is
not reflected in the first figure of the "threats" draft.  I've
now stated this at least five time, time to get a ticket.  Bye

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 11:39:13 -0500

Steve,

The threats are based on what SSP defines. Getting this straight now is
important.

Atleast the confirm the current meaning of the drafts.  I was told I was
wrong and I don't think so. Michael was shown incorrect logic while back
(how the pseudo code was incorrect) and he chose to ignore the input.  I
can't help that, but to find out now that all my analysis and
interpretation of this proposal is FLAWED, well, he better correct it or
back it up.

Not having this straight will cost us time and money. I am not going to
wait 1, 2 or 3 or 6 months or 1 year from now to find out what we have
is all incorrect (I don't think so), but before we go any further we
should get this resolved now.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 27 Jan 2006 16:48:38 +0000

Hi Hector,

> should get this resolved now.

In my mind this is a subtlety of SSP as it is now, (and like John L
hinted maybe), I could see the WG consensus landing on either side.

I don't see why this needs to be finalised now, but why don't you
create an issue for it, that way we *will* get back to it.

The important thing to note though is that stuff like this will
change in SSP before it becomes an RFC. AFAIK, there's never been
any similar I-D that didn't undergo similar changes.

So, I'm afraid you do have to wait,
Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 27 Jan 2006 13:05:36 -0500

----- Original Message -----

> hinted maybe), I could see the WG consensus landing on either side.

It is unfortuate John gets to lick his chops on this. Just because he
didn't understand the specs, doesn't mean no one else does either.

It causes alot of delays and it seems alot of time was wasted that ALL
IMPUT was ignored.

We need to make sure that PEOPLE that do understand the specs and are
not getting wrong impressions.

We are talking about an EXCLUSIVE POLICY, the "OH equal !" policy for
the layman impaired.

This is the biggest, the numero UNO benefit of DKIM.  As it is written,
it implies:

      Mail must be signed by the original domain.
      Mail must NEVER be signed by a 3rd party.

This is extremely fundamental to the protocol.  If this interpretation
is wrong, I would like to KNOW exactly with this OH equal ! means.

Was Michael saying that a 3rd party service can masquarade itself as the
original domain?

Earl, Arvel, and I, including Mike all touched based with this about 6+
months ago.  But as possible new policies or changes to the specs.  As
it is written now, it is exclusive OA Domain only, No 3rd party policy.

> create an issue for it, that way we *will* get back to it.

I could do that, but this was already spelled out many months ago.

> So, I'm afraid you do have to wait,

For what, the FINAL RFC?  You are kidding?

I can't even get a common courtesy of a clarification and confirmation
of the exclusive (O=!) policy?

---

From: Jim Fenton <[email-masked]>
Date: Fri, 27 Jan 2006 12:30:22 -0800

> mean 3rd party signer, not associated with "from".
It's already a third-party signer any time i= (or its default value if
it's absent) doesn't match the From address.  It doesn't have to be empty.
> (i.e. its clean and uses good anti-spam and anti-forger policies, etc.)
Associating the signature with the signing host (or listname@host) is
what I expect a mailing list would do.  But the reputation decision is
required to really know that it's a list.  It's not sufficient to see a
list-id or any other header field to know its role.
>
>> But it's the signer's assertion what their role is:  one might
>> imagine setting up a rule, "I'll accept any messages re-signed by
>> mailing lists."  So the Bad Actors will just start adding a few more
>> headers, and all of a sudden you're getting lots of mail from the
I get lots of falsified Received header fields.
>> which gives the responsible address as
We agree on this.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 27 Jan 2006 13:11:36 -0800

Hector,

Perhaps part of the disconnect here is the question of whether the
policy applies to the validity of the message or to the validity of
individual signatures.

John's original question is premised on the idea that there may be
multiple signatures on a message.  Let's take it as a given for now that
there may be.

The ! (EXCLUSIVE) policy says "Third-party signatures SHOULD NOT be
accepted".  So if a message with an OA signature and a third party is
verified, and the SSP is EXCLUSIVE, then the third-party signature
SHOULD be ignored, leaving the OA signature.  The message isn't
considered Suspicious if the message has a valid OA signature.  In other
words, it doesn't say "messages with third-party signatures SHOULD NOT
be accepted", it says that the third-party signature itself SHOULD NOT be.

I agree with many that it doesn't make a lot of sense to put a
third-party signature on a message that has an EXCLUSIVE SSP.  But I
don't see why it should harm the message to do so, so long as applying
the new signature doesn't break one that's already there.  The verifier
has to check SSP regardless (unless it verifies that there is a valid OA
signature first); it should be up to the re-signer to decide whether to
also check SSP or not.

-Jim

P.S.: I'll echo Stephen's request for more comments on the threat
analysis document.  I KNOW it isn't perfect!

---

From: John Levine <[email-masked]>
Date: 27 Jan 2006 22:37:22 -0000

>list-id or any other header field to know its role.

I don't understand why you need to know it's a list.  If phoo.com has
a good reputation, why does it matter whether it's signing list mail
or individual love letters?

Anyway, on my system the lists all live in separate subdomains to make
them easier to manage, the signature would likely be in its own domain
separate from the one that love letters use anyway, so if the lists
were notably better or worse than the individual messages, they'd have
a separate reputation domain anyway.

R's,
John

PS: Now I'm REALLY going to get back to the threats doc.
_______________________________________________
ietf-dkim mailing list
http://dkim.org

---

From: Jim Fenton <[email-masked]>
Date: Fri, 27 Jan 2006 14:57:37 -0800

> or individual love letters?
I wasn't asserting that you need to know it's a list.  I was responding
to William who had said that determining the role of the signer was
useful, and I was describing the problems associated with determining that.
> PS: Now I'm REALLY going to get back to the threats doc.
REALLY good.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 28 Jan 2006 05:59:24 -0500

Jim,

I appreciated your clarification of the Exclusive (o=!) policy.

First, I must say I had to get over the shock value of this revelation
and fundamental miscalculation.   This changes everything. I am vexed as
to how this fell thru the cracks. Rest assured if I had realized this
last year, it would of been topic of debate to atleast get it very clear
what this policy meant as it initially drafted.

A lot of time wasted and what I really don't appreciate is the lack of
professional courtesy from the key cogs and authors for not clearing
this up very early on for one simple reason:

   The term EXCLUSIVE introduced to label the symbolic O=! policy,
   was semantically, literally and technically incorrect to be used
   for this specific SSP.

>From Dictionary.dom:

1. Excluding or tending to exclude: exclusive barriers.

2. Not allowing something else; incompatible:
   mutually exclusive conditions.

3. Not divided or shared with others: exclusive
   publishing rights.

4. Not accompanied by others; single or sole: your
   exclusive function.

5. Complete; undivided: gained their exclusive attention.

and so on.  It should had not been used or allowed to be used in SSP
discussion, especially in the IETF meeting presentations. It was
incorrect.

In all fairness, it all make sense now.  I can see now why you
commented, there might not be a difference between STRONG and EXCLUSIVE
and that they could be folded.  In this case, I think you are correct.
There is no difference now.  But then again, you probably meant
something else. :-)

This changes months of proposed protocol technical analysis and software
modeling 100% based on having a fundamental engineering concept of
always having ideal baseline conditions or two absolute guarantee
extreme end points in the spectrum of possible results. In this case,
EXCLUSIVE (O=!) and NEVER (O=.)

This changes everything:

 - Foremost, the security of the protocol. There is no longer an
   absolute ideal end point of exclusive protection.  The protocol
   is now entirely made up using 100% relaxed provisions, which

 - Creates new potential entry points to analyze, and which

 - Creats a new series of assertions that need to be proved.

I will go ahead and provide input with "NEW ISSUES" in the TA.  I do
hope this is reconsidered and changed because if DKIM is made of 100% of
relaxed conditions with no absolutes (and the only one now is NEVER), it
will be very difficult me to have any incentive to continue supporting
this protocol purely based on its technical merits.

Thanks for listening.

---

From: "william(at)elan.net" <[email-masked]>
Date: Sat, 28 Jan 2006 14:17:41 -0800 (PST)

> useful, and I was describing the problems associated with determining that.

Actually I do think that reputation should be done based on role.
I also think that even when its not role-specific, the roles could
play a 'role' in determining overall reputation general score as well.

So responding to John as to why its it would matter, the example would
be if organization used listserver and there was found a bug in the 
software that allowed to let lots of spam through. Depending on the 
company, their reputation may suffer considerably because of that,
but reputation of user email from that company (assuming corporate 
environment) would be different. This is just one example, I can give
an opposite one where reputation of users varies widely where as 
reputation of listservices would be constant and good.

Anyway, I'm afraid as others are pointing out this type of talk is
something that was explicitly ruled off-topic for the wg.

---

From: Douglas Otis <[email-masked]>
Date: Sat, 28 Jan 2006 14:34:35 -0800

On Jan 27, 2006, at 2:37 PM, John Levine wrote:

>> Associating the signature with the signing host (or listname@host)  
>> is what I expect a mailing list would do.  But the reputation  
>> decision is required to really know that it's a list.  It's not  
>> sufficient to see a list-id or any other header field to know its  
>> role.
>
> I don't understand why you need to know it's a list.  If phoo.com  
> has a good reputation, why does it matter whether it's signing list  
> mail or individual love letters?

A DKIM signing-domain may not prove suitable for white-listing when  
replay abuse can not be controlled adequately.  There is no means to  
vet individuals for low cost or free services.  Perhaps the DKIM  
signing-domain may be limited to block-listing.  As such, DKIM will  
offer little acceptance value as bad actors might  not sign their  
messages or stage abusive message replays when their messages are  
signed.

There could still be value obtained by DKIM as an indication of the  
message source, simply to prevent spoofing.  Assume there is a next  
generation MUA or mail-filter.  You may wish to have messages marked  
when the source for a particular entity has been confirmed.  At the  
same time, you may also wish to be alerted when there appears to be a  
spoof of that message.  Perhaps this would allow you to update the  
registry that contains sources of important correspondents.  By  
allowing the signer to purport their role, these messages would not  
be marked as being a valid source for these important messages  
(unless these sources were also registered) and thus would not create  
false conflict alerts.

> Anyway, on my system the lists all live in separate subdomains to  
> make them easier to manage, the signature would likely be in its  
> own domain separate from the one that love letters use anyway, so  
> if the lists were notably better or worse than the individual  
> messages, they'd have a separate reputation domain anyway.

This may be true for this case, but it would not always be true.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Sat, 28 Jan 2006 21:22:06 -0800

Hector,

> > what this policy meant as it initially drafted.
Please don't overreact.  I would have spoken up sooner if I had
understood the disconnect and if I thought that your interpretation was
as broken as you seem to think it is.  I think only minor adjustments
are necessary.

> >    was semantically, literally and technically incorrect to be used
I mostly disagree; see definitions below.

> > 3. Not divided or shared with others: exclusive
This is the definition that I think fits.  The originating domain does
not want to share the right to apply a valid signature to its messages
with re-signers.

There is one sense where the term "exclusive" may be inappropriate.  I
understand that there may be legal reasons, in Europe in particular,
that a domain not try to dictate the handling of messages by others.  In
that sense the o=! policy (practice) would mean "I sign all messages,
and do not send through lists and others that would necessitate
re-signing".  A verifier could then interpret that policy/practice in
much the same way, but the statement is now declarative, not
imperative.  I don't really know what the laws say and whether this
would help, but I suspect it might.

> > There is no difference now.  But then again, you probably meant
Did I say that?  I think there's an important difference between STRONG
and EXCLUSIVE.  Not many domains will be able to publish EXCLUSIVE
because only a minority actually adhere to those practices, but it's a
very useful statement for those that do to be able to make.

> >  - Creats a new series of assertions that need to be proved
> >   
I'll be interested in your new issues.  I don't think that much has
really changed; just that the validity of individual signatures, and not
entire messages, is affected by SSP.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 30 Jan 2006 01:53:32 -0500

----- Original Message -----

> as broken as you seem to think it is.  I think only minor adjustments

In this chart produced over 6 months ago, you, Eric and among others all
indicated a "I like this chart" statement:

| PASS 3PS  | reject | accept  | accept  | REJECT | reject | warn  |
| FAIL 3PS  | reject | warn    | warn    | REJECT | reject | warn  |

It clearly shows in the EXCLU/REQ column, that there was a REJECT
condition for both the PASS 3PS (valid 3rd party signature) and the FAIL
3PS (invalid 3rd party signature).  This was due to "my" intepretation
of this O=! policy.

But we now know it would be incorrect according to the correct intent of
this SSP draft O=! policy.

Instead, the PASS 3PS is not reject but a ACCEPT.  The FAIL 3PS is not
reject, but mostly a warning now or accept depending ignore the 3PS.
Hence, you can see how EXCLUSIVE could fold into a STRONG policy.

So in essence, I misread the policy, and everyone else must of
misunderstood this chart because it was too obvious to point the
discrepency.  I am no longer sure if you understood the purpose of the
chart.  But I will say, many columns now do fold simply because of the
relaxed definition of the O=! policy.

In fact, now that it is cleared, when applying Michael's statement and
pseudo-code DKIM verifier logic:

       "SSP is not for signed mail, it is for unsigned mail."

the chart is now reduced to one verify NONE condition:

When you compare the two tables for loopholes conditions, the loopholes
would be in not checking for unauthorized 3rd party signing.

So for the logic to be correct, it would more closely follow:

       "SSP is for unsigned mail and 3rd party signed mail."

But then again, this all depends on the intepretation of ALLOW or NOT
ALLOW 3rd party signing policies.  I understand now it is more
declarative, and not imperative.

To me that is a mistake. It increases risk and uncertainty and it will
be surely be exploited, making the payoff of DKIM processing much less.
So yes, it is a big thing.  The 3PS issues needs to get resolved pretty
quickly because it defines much of what the threats will be.

The bottom line is that there is no longer any absolute "exclusive"
protection for a domain who wishes to use such a policy.

Finally, I think you are underestimating how many domains will be
interested in a "TRUE" exclusive policy.  But then again, that only
applies if SSP is followed.

---

From: Jim Fenton <[email-masked]>
Date: Mon, 30 Jan 2006 18:32:23 -0800

Hector Santos wrote:
>> understood the disconnect and if I thought that your interpretation
>>     
> was
>   
What I said (http://mipassoc.org/pipermail/ietf-dkim/2005q4/001242.html)
was:
> I really like Hector's table, and the terminology he has introduced to
> make it easier to talk about the SSP policies.  I think we still need
> to talk through the specifics of the table once we get chartered, as
> there will be some disagreement over the content of specific cells. 
> For example, I'm not convinced of the utility of the "weak" policy. 
> But that's good stuff to address once we get chartered.
So I don't think I'm contradicting myself, and I don't think we need to
work out the details for the -threats document, which is our current focus.

>        "SSP is for unsigned mail and 3rd party signed mail."
This aligns with my view of SSP, and the non-requirement to consult SSP
if there is a valid originator address signature.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 30 Jan 2006 22:46:45 -0500

----- Original Message -----
From: "Jim Fenton" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> What I said
(http://mipassoc.org/pipermail/ietf-dkim/2005q4/001242.html)

> So I don't think I'm contradicting myself, and I don't think
> we need to work out the details for the -threats document,
> which is our current focus.

Jim, I never said you did contradicted yourself. I thought we were on
the same wavelength. :-)

Actually, I believe it was a different discussion thread. You didn't
like the term EXCLUSIVE or something like that, let me look.... ok.. It
was July 22 in the IETF-MAILSIG mailing list,

http://www.imc.org/ietf-mailsig/mail-archive/msg01673.html

    "I like this.  I have been using the word "stronger" to
    describe what you're calling "exclusive", but I can change
    my habits.

    -Jim"

You were correct. The proper term would be a STRONGER policy. Bank a
million bucks on it, guaranteed. I would absolutely never in my right
mind, ever called it "EXCLUSIVE" nor continue to use it in this context
for the next 6 months if I had realized this O=! policy allowed for
unknown entities to screw around with the message with detailed
operational recommendations to ignore 3rd party signatures and deemed
this to be an valid message.

But its moot point now.  Its all squared now. :-)

> if there is a valid originator address signature.

Inventor clarification restated, included with the decisively worked out
non-requirement operational detail for a valid OA signature.  :-)

Thanks Jim