Subject: [ietf-dkim] "I sign everything" is not a useful policy

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 14:58:30 -0700

What seems abundantly clear is that the unqualified policy "I sign 
everthing"
is not useful as is, and is most likely harmful due to differences in 
the way
that people interpret what that statement means.

I invite people for the requirements to make *precise* statements of the
fully qualified meaning in their heads about "I sign everything", and
preferably in a sentence or less as that is what the world is going to
actually think of when they deploy this.

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

---

From: Damon <[email-masked]>
Date: Fri, 4 Aug 2006 19:27:19 -0400

> actually think of when they deploy this.

It is my opinion that in its current state "I SIGN ALL" is inferring
an absolute and will most likely be treated by both senders and
receivers as such. Therefore, a failure will likely be treated with
extreme prejudice by the receiver regardless of this groups suggested
usage and will completely undermine the senders expected value of
signing in this manner.

Regards,
Damon Sauer

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 19:35:19 -0400

Mike,

As the topic title is stated it is a open-ended totally mangled concept. "I
sign everything" is not very clear and specific so as you saw, it is open to
a wide range of interpretations and I suggested asking for a "definition" is
not going to give you the result you are seeking.

The commonality in all the semantics is the idea of exclusive 1st party only
domain signatures versus allowing for 3rd party signatures.

That's been the argument say day one with the SSP stated policy tags:

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

Which I labeled for ease of communications, the EXCLUSIVE signing policy.

Yet,  according to you, this semantic is not quite correct. It is not an
exclusive policy.

We made it more clear by breaking it up into two axle which many here got
excited with added their own ideas for describing it, including Tony Hansen,
Frank Ellerman,  William, among others.

In DSAP, I wrote it up as:

    OP=ALWAYS;3P=NEVER;

All the combinations are possible with using OP vs. 3P methodology and what
is really great about it is that the signer is free is to use whatever he
wants and it covers ALL possible USE CASES.

4.2.  DSAP Tags: op=<signing-policy>; 3p=<signing-policy>;

   From the viewpoint of the verifier, when a message is received, there
   are two basic pieces of signature information to be of interest when
   analyzing the transaction:

   o  Original Party Signatures (OP)

      *  never expected
      *  always expected
      *  optional

   o  3rd Party Signatures (3P)

      *  never expected
      *  always expected
      *  optional

   When the two signature types are combines, the possible policies are
   listed in this following table:

    +=================================================================+
    | op=         | 3p=        | Domain Policy Semantics              |
    |=================================================================|
    | empty       | empty      | No mail expected                     |
    |-----------------------------------------------------------------|
    | never       | never      | No signing expected                  |
    | never       | always     | Only 3P signing expected             |
    | never       | optional   | Only 3P signing optional             |
    |-----------------------------------------------------------------|
    | always      | never      | OP signature expected                |
    | always      | always     | Both parties expected                |
    | always      | optional   | OP expected, 3P may sign             |
    |-----------------------------------------------------------------|
    | optional    | never      | Only OP signing expected             |
    | optional    | always     | OP expected, 3P expected             |
    | optional    | optional   | Both parties may sign.               |
    +-----------------------------------------------------------------+

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

---

From: Douglas Otis <[email-masked]>
Date: Fri, 4 Aug 2006 18:11:49 -0700

On Aug 4, 2006, at 4:35 PM, Hector Santos wrote:

> As the topic title is stated it is a open-ended totally mangled  
> concept. "I sign everything" is not very clear and specific so as  
> you saw, it is open to a wide range of interpretations and I  
> suggested asking for a "definition" is not going to give you the  
> result you are seeking.

An "I sign everything" would be perfect as a DKIM client policy.   
This is not very suitable for a DKIM From policy.

A DKIM From policy should be little more than a list of authoritative  
domains with a flag that indicates whether the list is complete.

> All the combinations are possible with using OP vs. 3P methodology  
> and what is really great about it is that the signer is free is to  
> use whatever he wants and it covers ALL possible USE CASES.
>

This approach is clumsy when attempting to handle a list of  
designated signing domains that may or may not include the From  
domain. : (

Consider a list _is_ the policy where a period "." indicates that a  
list is complete.  In other words, a period "." would provide the  
verifier a stipulation that various services such as mailing-lists or  
e-invites are not used.  With this list, there is no need for a  
complex matrix of never, always, optional, or sometimes.  With a  
list, DKIM From policy becomes:

(example.com, dkim-from-policy)
"DKIM-FP: ."
-> No authoritative sources used.  Sends no mail.

(example.com, dkim-from-policy)
"DKIM-FP: *.example.com, my-isp.com, my-ad-agency.com, my-other- 
isp.com, my-collection-agency.com, ."
-> Uses the listed authoritative domains and no non-complaint services.

(example.com, dkim-from-policy)
"DKIM-FP: *.example.com, ."
-> Only example.com and its subdomains are authoritative and no non- 
complaint service used.

(example.com, dkim-from-policy)
"DKIM-FP: my-work-domain.com, ."
-> Only my-work-domain.com is authoritative and no non-complaint  
service used.

The default:
(example.com, dkim-from-policy)
"DKIM-FP:"
-> Uses undefined sources that may or may not sign.

The recommended method for listing policy would be:
(example.com, dkim-from-policy)
"DKIM-FP: *.example.com"
-> Only example.com and its subdomains are authoritative, but non- 
complaint service are also used.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 4 Aug 2006 22:22:19 -0400

> The matrix only enumerates the possibilities, not who or why one
> would select those possibilities, and what they're hoping a
> reciever will do with the information.  It's the who and why
> we need answers for.

Mike,

You are 100% correct and if it makes it easier I will do this in more
detail.

If you check out the DSAP section 5, the draft does begin to offer some "who
and whys".  I felt from a protocol standpoint it really should not matter.
The main goal with DSAP and SSP for that matter was to describe the boundary
conditions. The compromise and solution here is to go thru the technical
possibilities, locking them down, including removing ones we don't think is
appropriate.  But we would need to also document the PAIRs which will not be
supported because if we don't, that opens a threat entry point for abuse.

Ok, let me put my business hat on and describe the WHO/WHY for each. Of
course, I will not cover all possible creative uses, but I do have a few
good ideas on how they can be used, and I will submit that some that are
probably not necessary or can be folded.  Also, the syntax shown is for
illustration. I am not locked into any specify form, but it was an agreed
upon format among reviewers.

Overall there are ten policies:

    OP=;3P=;               | Empty, No Mail Policy

This is for domains which are not used for email. The spectrum of users is
across the board, specifically those who have a web, ftp domain or other
service type but email.  This will help address the spoofing of domains by
bad guys using domains that were not intended for email against other
DKIM-SSP compliant verifiers.

    OP=NEVER;3P=NEVER;      | No signing expected

This is for domains that fall into two possible categories; those who have
no interest in DKIM and it is telling the world DO NOT expect anyone to be
signing mail from these domains.  This will help verifiers filter the
spoofers using this domains inappropriately.  In addition, it will help
serve the ISP/ESP market who will begin to offer signing services.  The
domain may not want to pay for signing?  The domain may want to turn off any
ISP/ESP signing.  These DOMAIN/ESP service contract ideas were covered the
old mailing. If a domain is using a ISP/ESP bent on signing all mail, should
this be forced down the domain throat?  Of course, he can leave the ISP/ESP
if he doesn't like the new ISP/ESP policy, but why lose customers if the
domain doesn't want his mail signed?  Just allow the domain to declare this
policy and the verifiers will help protect against any DKIM spoofing.

    OP=NEVER;3P=ALWAYS;    | Only 3P signing expected
    OP=NEVER;3P=OPTIONAL;  | Only 3P signing optional

This pair is designed for Service Bureaus, IPS or EPS who offer 3rd party
signing services.  The EPS/ISP may offer a free or fee base signing service
targeted at local hosted domains and/or users.  The business opportunities
here are great.

Please note that the ISP/ESP market can offer and support all policies so I
won't bother to mention this market in detail again.

    OP=ALWAYS;3P=NEVER;     | OP signature expected only

This is what I call the "Exclusive Policy" for domains who do not want to
have any risk whatsoever in sending an email directly to a user.  ISP this
is highly desirable policy across the board, I can see high-value
organization taken advantage of this policy. John's lawyer, Jill's Bank,
Billy's doctor in the next generation eMedical market. All these domains
want 100% surviability and they will probably be more prudent on who they
send this type of mail too. So they might be adding failure pre-emption
methods. However, as well noted in the group, survivability may not
guaranteed depending the path, the hops, etc.  Thus success rate is
increased as more DKIM-SSP compliant systems are adopted and they begin to
honor the exclusive policy.  The short term workaround is the next two
policies.

    OP=ALWAYS;3P=ALWAYS;    | Both parties expected
    OP=ALWAYS;3P=OPTIONAL;  | OP expected, 3P may sign

This are for domains who want to sign all their mail but are going to allow
or may expect middle ware applications to make any corrections, if need be.
Although I consider this increases the potential for unknown abuse, it also
increases the survivability of the transport.

    OP=OPTIONAL;3P=NEVER;    | Only OP signing expected, if any

This policy can probably be used by a single domain who wishes to signed
mail for private direct email conversations, and also use the same domain
for unsigned messages for external public use (i.e. mailing list) where
survivability is low.  This is implementation based with the software
allowing the domain to select or exclude which target domains are signed or
not.

    OP=OPTIONAL;3P=ALWAYS;   | OP may sign, 3P always expected

This falls into the ISP/ESP business market I described above, in the case,
the ISP/ESP has sold or has mandated an also signed concept for his system.
However, I do think the domain should have control on signing. The ISP/ESP
should offer the domain the ability to turn off 3rd party signing.

    OP=OPTIONAL;3P=OPTIONAL  | Both parties may sign.

Again, this can be just about anyone, but I think it will the software that
will make use of this for the domain or user to use on a per target address
basis possibly.

I hope this helps. From my standpoint, each policy is possible in the real
world.  But some are more complex to handle, but that is an implementation
issue and I don't see a real big problem with that as long as we can set
such boundary conditions.  As we always new, the hardest will be the MLS
(Mailing List Server). But the only solution I see is the domain itself
being a lot smarter on what policy to use within a MLS environment and the
MLS helping by using doing some pre-emptive policy checking action itself.

---

From: Mark Delany <[email-masked]>
Date: Sat, 5 Aug 2006 02:58:00 +0000

> actually think of when they deploy this.

"I sign all": Your users and my business may be harmed by accepting
unverified mail claiming to originate from my domain. It is in our
mutual interest for you to not deliver such mail to your users.

I am an adult of voting age and accept the possibility that
deliverability of my traffic may reduce as a consequence.

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 04 Aug 2006 17:47:41 -0700

The matrix only enumerates the possibilities, not who or why one would
select those possibilities, and what they're hoping a reciever will do with
the information.  It's the who and why we need answers for.

       Mike

---

From: <[email-masked]>
Date: Fri, 4 Aug 2006 23:18:13 -0400

+1

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Mark Delany
Sent: Friday, August 04, 2006 10:58 PM
To: [email-masked]
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy

On Fri, Aug 04, 2006 at 02:58:30PM -0700, Michael Thomas allegedly

Mark.

---

From: Arvel Hathcock <[email-masked]>
Date: Sat, 05 Aug 2006 09:40:55 -0500

> deliverability of my traffic may reduce as a consequence.

Yes, +1.  This is the way I've understood the "I sign all" policy since 
forever.

-- 
Arvel

---

From: John Levine <[email-masked]>
Date: 5 Aug 2006 17:41:07 -0000

>deliverability of my traffic may reduce as a consequence.

If "I sign all" means anything at all, this is what it means.

R's,
John

---

From: <[email-masked]>
Date: Sat, 5 Aug 2006 19:23:34 -0400

Your assertion in the subject is an opinion.  I find the statement below
to be useful.
Thanks,
Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John Levine
Sent: Saturday, August 05, 2006 1:41 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy

R's,
John

---

From: John L <[email-masked]>
Date: Sat, 5 Aug 2006 19:27:30 -0400 (EDT)

> Your assertion in the subject is an opinion.  I find the statement below

I think we have a subtle point here.

"I sign everything so please discard unsigned mail apparently from me" 
could be useful to recipients.

Plain "I sign everything" isn't.

R's,
John

---

From: <[email-masked]>
Date: Sat, 5 Aug 2006 19:37:22 -0400

No point at all, that is what we are supposed to be doing here, defining
policy then hashing out what that policy clearly means with a consensus
of the WG. I don't want to be on a technical call 2 years from now
discussing what the policy means like I had to do with WICIS. Lets set
an agreeable policy, discuss what it means (like the statement below)
and the write the document with the clear expectation of what it means.

1. I sign all

The above means "I sign everything so please discard unsigned mail
apparently from me"

There, one policy statement done.

Thanks,
Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: John L [mailto:[email-masked]] 
Sent: Saturday, August 05, 2006 7:28 PM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]; [email-masked]
Subject: RE: [ietf-dkim] "I sign everything" is not a useful policy

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Sat, 5 Aug 2006 16:42:18 -0700

> If "I sign all" means anything at all, this is what it means.

To prevent DKIM from creating delivery problems for those wanting to  
indicate a signing domain relationship with their From domain, "I  
sign all" should be couched slightly differently.

Policy assertion suitable for normal use:

"Listed domains sign all messages for From domain" Any message  
appearing to be issued directly from one of the listed domains SHOULD  
have a valid DKIM signature.  It would be in the signing and  
verifying domain's mutual interest for messages with invalid  
signatures that are subject to this policy to not be delivered,  
unless they appear to be on behalf of this domain from a known  
reputable source.

Suitable for domains that are phishing targets:

"Listed domains sign all messages for From domains _and_ non- 
complaint services are not used" Any message from one of the listed  
domains MUST have a valid DKIM signature.   It would be in the  
signing and verifying domain's mutual interest for messages with  
invalid signatures that are subject to this policy to not be  
delivered.  No exceptions!

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 5 Aug 2006 19:48:14 -0400

----- Original Message -----
From: "John Levine" <[email-masked]>
To: <[email-masked]>
Sent: Saturday, August 05, 2006 1:41 PM
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy

> If "I sign all" means anything at all, this is what it means.

That is what it meant since day one. There was absolutely no FOG in that
view because Local policy always dictate what's acceptable or not.  But if
its gets a domain hint for what was expected or not expected, rest assured
it will be subject to rejection with no qualms about it.

As it is now, we have to accept the PAYLOAD failure and let the user decide
if its BAD or GOOD.  What's change?

The problem?

This is the bad guys' cat's meow! Fake it to you make it, random unsolicited
attacks based on an unprotected DKIM "ignore failure" methodology.

---

From: Steve Atkins <[email-masked]>
Date: Sat, 5 Aug 2006 16:50:59 -0700

> The above means "I sign everything so please discard unsigned mail

Where "unsigned" means any mail other than DKIM signed
mail which validates correctly when received by the recipient.

(It seems a minor point, but several people here have asserted that
mail for which the signature doesn't validate is not "unsigned").

> There, one policy statement done.

Well, a use case to go with it would be nice.

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Sat, 05 Aug 2006 16:57:23 -0700

> Plain "I sign everything" isn't.

Having the signer or the ssp publishes tell the evaluator what they should do
with a message is not a good idea, even though it might well seem obvious what
they should do.  That is why my wording for 'i sign everything' is phrased
rather differently than folks are bandying about in this thread.

d/

-- 

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

---

From: Mark Delany <[email-masked]>
Date: Sun, 6 Aug 2006 00:44:43 +0000

On Sat, Aug 05, 2006 at 04:57:23PM -0700, Dave Crocker allegedly wrote:
> with a message is not a good idea

Why do you say that Dave?

If SSP is not giving guidance/information to receivers/evaluators, who
then is the target audience for SSP? And what do we want them to do
with the information?

An interesting twist to "telling evaluators", as you put it, is that
SSP is a negative indicator. It's telling evaluators *not* to deliver
unless the right conditions are met. Why would an "evaluator" be
suspicious of a domain that encourages non-delivery of its own traffic
when in doubt?

Mark.

---

From: <[email-masked]>
Date: Sat, 5 Aug 2006 20:48:05 -0400

An invalid signature is not unsigned, but we are not discussing that
policy point yet :-)

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Steve Atkins
Sent: Saturday, August 05, 2006 7:51 PM
To: DKIM List
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy

Cheers,
   Steve

---

From: Dave Crocker <[email-masked]>
Date: Sat, 05 Aug 2006 18:06:59 -0700

> suspicious of a domain that encourages non-delivery of its own traffic

The signer knows everything there is about their own behaviors.  They cannot
know very much about the context, needs, preferences, or much else about the
evaluator.  Therefore they cannot know very much about what the evaluator
"should" do with a message.

Seriously.  SSP can be entirely useful when stated in terms of the sender's
perspective.  It does not need to pretend that is knows enough to give
directions to an evaluator.

We have done quite a good job, so far, of distinguishing statements about
signing from statements about delivery or non-delivery.  The issue is not
whether the evaluator might be "suspicious" of a direction to perform
non-delivery.  It is that it crosses a line into making presumptions about the
evaluator that a) the Internet technical community does not have experience
with, and b) we do not need to cross.

d/
-- 

  Dave Crocker

---

From: Mark Delany <[email-masked]>
Date: Sun, 6 Aug 2006 01:45:36 +0000

> directions to an evaluator.

Sorry for being dense, but I have to ask the question again. Who is
the target audience for the "sender's perspective" if not the
evaluator? Put in my blunt language. Why publish an SSP if no one
listens?

Dave, I know you are subtle about such things and the purposeful
disconnect that is lost on me, clearly has merit to you. Can you use
simple words and help me out? Of course SSP can only be advisory at
best, but is their more to your perspective than that?

Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 6 Aug 2006 00:01:09 -0400

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

> If I choose to deliver unsigned mail that purports to be from a
> domain that says it signs everything, but I mark it up with flashing
> lights that say "spoofed" do you want that to be a protocol violation?

Yes.  I am not what you mean by "But i mark it up with.." by yes, if the
domain expectations for a valid transactions are broken, in order to protect
his reputation inherited by a DKIM-BASE mandate, he would prerfer it to be a
protocol violation.

> What about my choosing to send it to
> my sysadmin for special handling for spoofed mail?  What about...

Thats up to you and local system policy.  That should take away the domain
declaration for his expectatons for a valid transaction.

> In other words, there are lots of things that I might reasonably
> choose to do with mail that I receive that violates one or
> another SSP statement.

I am not sure I follow the logic, but this is all really simple.  The domain
told you want is expected for a valid message. It went thru all the work on
signing messages for some reason that hopefully has some payoff when things
go wrong with it.  Isn't the essense of a security protocol? When the
protocol is not followed?

> It is not the publisher's right or responsibility to tell me what to do
with
> information. By contrast it is entirely reasonable for them to provide me
with
> information that I am likely to find helpful.

Agree. And sure, as a receiver, you can decide to do what you want.  But if
we are talking about helping to stop or control abuse, then I think most
receivers are very interested in technology that will help in the area.

> A signer should make statements that a) the signer believes to
> be important, and b) there is a good basis for believing that
> evaluators will consider important.

Isn't this what SSP draft, including DSAP I-D draft already does and
documents?

Have you looked at this documents?   What is wrong with them?  Do you trust
the engineering done?   What's missing?

---

From: Dave Crocker <[email-masked]>
Date: Sat, 05 Aug 2006 19:21:59 -0700

Mark Delany wrote:
> Sorry for being dense, but I have to ask the question again. Who is the
> target audience for the "sender's perspective" if not the evaluator? Put in
> my blunt language. Why publish an SSP if no one listens?

Mark, it's ok if you are dense.  It forces me to (try to) be more clear:

I did not say that the evaluator should or would pay no attention to the SSP
information.  What I am saying is that there is a difference between telling
someone what *I* do versus telling them what *they* should do.

If I choose to deliver unsigned mail that purports to be from a domain that says
it signs everything, but I mark it up with flashing lights that say "spoofed" do
you want that to be a protocol violation? What about my choosing to send it to
my sysadmin for special handling for spoofed mail?  What about...

In other words, there are lots of things that I might reasonably choose to do
with mail that I receive that violates one or another SSP statement.

It is not the publisher's right or responsibility to tell me what to do with
information. By contrast it is entirely reasonable for them to provide me with
information that I am likely to find helpful.

> Dave, I know you are subtle about such things and the purposeful disconnect
> that is lost on me, clearly has merit to you. Can you use simple words and
> help me out? Of course SSP can only be advisory at best, but is their more to
> your perspective than that?

A signer should make statements that a) the signer believes to be important, and
b) there is a good basis for believing that evaluators will consider important.

A signer should not direct the evaluator what is to be done with that information.

I do not see this distinction as small or subtle.

John Levine's note:
>> When I think of SSP records saying dump mail if it's not signed, I see a
>> bunch of tiny gorillas*, beating their teensy chests and saying in high
>> squeaky voices, "Beware, oh Internet, of the Scourge of Criminals
>> attempting to forge the image of my Inestimable Personage, and do not
>> DARE to be fooled by these Base Mockeries of Communication!"  The only
>> reasonable response from everyone else is somewhere between "Huh?" and
>> "Get real."
>> 
>> If the ABA or the FDIC published a list of domains used by member banks
>> to send signed transactional mail, I would find that really useful.  A
>> list of people who think they are as threatened by forgery as those
>> banks is useless other than for entertainment value.
>> 
>> So that's the problem with SSP.  Whatever your policy is, unless you're
>> someone I already have reason to be interested in, I don't care.

seems to be getting at the same point:

     It's fine for you to tell me interesting stuff, but please do not pretend
to tell me what to do with it.

d/

-- 

  Dave Crocker

---

From: <[email-masked]>
Date: Sun, 6 Aug 2006 00:23:43 -0400

Hector,
The engineering part is easy, what is extremely difficult is the policy.
After spending a long period of time debating what the word UNIQUE means
in a policy document that has some similarities to email, I want to get
it right the first time. Make sure the rules are simple. Ensure there is
agreement. Make sure a clean unambiguous meaning is set to every
possibility.
Its harder than it looks.

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Hector Santos
Sent: Sunday, August 06, 2006 12:01 AM
To: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy

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

Yes.  I am not what you mean by "But i mark it up with.." by yes, if the
domain expectations for a valid transactions are broken, in order to
protect
his reputation inherited by a DKIM-BASE mandate, he would prerfer it to
be a
protocol violation.

> my sysadmin for special handling for spoofed mail?  What about...

Thats up to you and local system policy.  That should take away the
domain
declaration for his expectatons for a valid transaction.

> choose to do with mail that I receive that violates one or

I am not sure I follow the logic, but this is all really simple.  The
domain
told you want is expected for a valid message. It went thru all the work
on
signing messages for some reason that hopefully has some payoff when
things
go wrong with it.  Isn't the essense of a security protocol? When the
protocol is not followed?

with
with
> information that I am likely to find helpful.

Agree. And sure, as a receiver, you can decide to do what you want.  But
if
we are talking about helping to stop or control abuse, then I think most
receivers are very interested in technology that will help in the area.

Have you looked at this documents?   What is wrong with them?  Do you
trust
the engineering done?   What's missing?

---

From: <[email-masked]>
Date: Sun, 6 Aug 2006 00:29:39 -0400

Dave,
You may deliver anything you wish, in any manner. It will only be a
protocol violation when a scmuddle determines that it may not have been
a very good idea. Policies and protocols are rules to ensure that finger
pointing is accurate.
Thanks,

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

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

with
with

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 6 Aug 2006 01:02:25 -0400

Bill,

Actually, IMV, the POLICY is the easiest part because that is already define
by the potential DKIM-BASE may exhibit.

It will be the engineering to get it done properly that may ultimately tell
us of the feasbiliity of it all which I am 100% capability of accepting way
away or another.

No, I don't think it is hardr at all. The possible policies are fixed.

Where did that come from anyway? "I sign all mail"  That isn't in SSP DRAFT,
in fact the SSP says for the o= tag:

 o= Outbound signing policy for the entity (plain-text; OPTIONAL,
    default is "~").  Possible values are as follows:

    ~  The entity signs some but not all email.

    -  All mail from the entity is signed; unsigned email MUST NOT be
       accepted, but email signed with a Verifier Acceptable Third
       Party Signature SHOULD be accepted.

    .  This entity never sends email.  The "." policy can be used to
       "short circuit" searches from subdomains; for example, the
       "ad.jp" domain might use this.  If an initial policy search
       receives this policy then the email SHOULD NOT be accepted; if
       found while searching parent domains then the search should
       terminate as though no policy record was found.

    ^  Repeat query at user level.  This value MUST NOT be used in
       user-level policy records.  A Verifier MUST look up the
       selector for "<user>._policy" where <user> is the local-part of
       the Originator Address (i.e., the portion of the address before
       the "@" character).

These is the SEMANTICS people should be debating.

Once you think about the engineering to statisfy these requirement,
including problems from a security standpoint, the loopholes, etc, then you
see my position better and why DSAP was done.

There is alot of time being wasted here by people who saying they don't
understand and then suggest it is the status quo, therefore lets water it
down without thinking about the security implications which are pretty
major.  No, it is extremely simple yet powerful concept.  The issue?  It is
feasible. Can it work? What will it take to work?  Is there a revamp and/or
migration issue here? etc.   No, the policies are simple.

In short, watering it down make be as bad as having nothing at all.

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Sunday, August 06, 2006 12:23 AM
Subject: RE: [ietf-dkim] "I sign everything" is not a useful policy

Hector,

Bill Oxley
Messaging Engineer
Cox Communications, Inc.
Alpharetta GA
404-847-6397
[email-masked]

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

with
with

---

From: Douglas Otis <[email-masked]>
Date: Sun, 6 Aug 2006 01:29:38 -0700

> in fact the SSP says for the o= tag:

SSP did not accommodate listing authoritative domains.  Assume any  
domain entered into the list indicates that it authoritatively signs  
all messages for the From domain.  Being within the list brings this  
domain to the same level as that of the From domain.

The list can include subdomains or exclude parent domains.  Being  
within the list could be viewed as "All messages carried for the From  
domain are authoritatively signed by domains within the list".   
Making this list exclusive or closed would stipulate that no other  
domains are used.  To illustrate, a "." is used for "closed" and  
example.com is the From domain.  When undefined domains carry the  
 From domain (the list is not closed), the reputation of the source  
acting on behalf of the From, rather than reliance upon a signature  
is required, as in the case of a mailing list.

>     ~  The entity signs some but not all email.
Change to:
  This domains and other domains that may sign are used:
DKIM-FP: <>

>        Party Signature SHOULD be accepted.
Changed to:
  All mail signed and other domains that may sign are used:
DKIM-FP: <*.example.com>

>     !  All mail from the entity is signed; Third-Party signatures
DKIM-FP: <*.example.com, .>

>        terminate as though no policy record was found.
DKIM-FP: <.>

>        the Originator Address (i.e., the portion of the address before
Deprecated.

With the list, other domains can be designated as being as  
authoritative as the From domain.
Foo.com can sign for example.com might be used as follows:

Only example.com and foo.com sign all messages and no other domains  
are used.
DKIM-FP: <example.com, foo.com, .>

Perhaps example.com never signs but foo.com does and mailing lists  
are used:
DKIM-FP: <foo.com>

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 6 Aug 2006 04:57:36 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Sunday, August 06, 2006 4:29 AM
Subject: Re: [ietf-dkim] List based policy

> > Where did that come from anyway? "I sign all mail"  That isn't in
> > SSP DRAFT, in fact the SSP says for the o= tag:
>

Agree.

Other than maybe using a different tag name than DKIM-FP,  I think the
changes or a fascimile you suggest are good. It addresses the key issues
discussed over the year regarding authorized domains.  I don't see a problem
off hand and see no reason to not consider your changes for SSP-02.

Thanks Doug

---

From: Frank Ellermann <[email-masked]>
Date: Sun, 06 Aug 2006 13:11:53 +0200

[email-masked] wrote:

> Lets set an agreeable policy, discuss what it means (like the
> statement below) and the write the document with the clear
> expectation of what it means.

> The above means "I sign everything so please discard unsigned
> mail apparently from me"

> There, one policy statement done.

Does this cover ALL messages with a "From: I sign everything",
or only messages where the PRA (~ CAD in Doug's terminology)
happens to be the same as "From: I sign everything" ?

Offering both options, as different policies, could make sense.

Frank

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 6 Aug 2006 08:59:30 -0400

----- Original Message -----
From: "Mark Delany" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, August 06, 2006 8:38 AM
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy

> DKIM+SSP is defining "damaged".

+1

SSP does not attempt to evaluate the reputation of the sender or client.  A
good intention client can use SSP as well as the bad  intention client.  The
main objective of SSP is to establish a  protocol consistency and to use the
deviation from the consistency as part of a failure detection system.

---

From: Mark Delany <[email-masked]>
Date: Sun, 6 Aug 2006 12:38:01 +0000

> my sysadmin for special handling for spoofed mail?  What about...

Well sure, but how about treating it the same as an IP checksum
failure?

You may divert it to some port for analysis - especially in the early
days - but what sort of stack delivers a known damaged packet to the
end point when the transmitter/protocol says to discard known damaged
packets?

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 06 Aug 2006 07:21:45 -0700

>Well sure, but how about treating it the same as an IP checksum

What this analogy is missing is that the checksum is being grafted on 
after the
fact such communication that used to get through stops happening in 
erratic and
unexplainable ways if the receiver just throws damaged messages away. Worse,
is that parts of the infrastructure do this kind of damage and think it 
is not only
a feature, but that it's their god-given right. If DKIM were part of RFC822
like checksums were in IP this would be a different situation, but it 
missed that
by about 25 years.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 06 Aug 2006 07:13:19 -0700

>directions to an evaluator.

 From what I can see, we are converging on a policy/practice where most 
domains
could make a completely correct statement: "I sign everything" and never 
want
to publish that policy given that the normal and expected transit damage 
of remailers,
etc. That tells me that as stated "I sign everything" is wrong. What 
people really
seem to be meaning is "you should find a valid (verifyable) first party
dkim signature" which is a lot different statement than "I sign 
everything".  It's
the expectation that this all really hinges on.

This toes the line of telling the receiver what to do, but it at least 
doesn't
go over the line by pointing out an acceptable form of execution (550, 
leathal injection,
etc). So it seems to me that what we really need here is some finesse of 
informing the
receiver of the sender's transit expectations without outright saying 
what to do.

       Mike

---

From: Michael Thomas <[email-masked]>
Date: Sun, 06 Aug 2006 08:16:33 -0700

Arvel Hathcock wrote:

> Yes, +1.  This is the way I've understood the "I sign all" policy 
> since forever.
>
Arvel: I'm pretty sure that Altn.com signs all of its mail. If that's the
case, then why are you publishing this SSP record:

_policy._domainkey.altn.com text "o=~; r=[email-masked]"

       Mike

---

From: Arvel Hathcock <[email-masked]>
Date: Sun, 06 Aug 2006 15:01:41 -0500

> Arvel: I'm pretty sure that Altn.com signs all of its mail. If that's
 > the case, then why are you publishing this SSP record:
 >
 > _policy._domainkey.altn.com text "o=~; r=[email-masked]

I suspect we could probably change that now.

My postmaster had asked for a relaxed policy during the past year mostly 
because I keep changing the code and have had a couple of instances 
where I rendered our signer incompatible with our verifier for a short 
time (Doh!).

-- 
Arvel

---

From: Dave Crocker <[email-masked]>
Date: Sun, 06 Aug 2006 14:37:47 -0700

>> it signs everything, but I mark it up with flashing lights that say "spoofed" do
...
> end point when the transmitter/protocol says to discard known damaged

Mark,

I am a great fan of looking to the experience of the lower layers, when trying
to develop mechanisms for applications, especially email.  So your suggestion is
an important one to consider.

I think the problem is that email's variations in the handling of its "packets"
make its environment too vastly different from the much simpler world of IP.

(I'll skip over my recollection that there have been activities that do partial
delivery on damaged IP datagrams. The standard says what you cite and it is a
more useful place to start, I think.)

What you espouse is probably where we all want this to get to.

The question is whether we can get there with a directive, at this point, in an
adjunct protocol that operates in the realm of a contingent, remote,
partially-adopted mechanism that changes the fundamentals of Internet mail
delivery?

And, of course, the way I've phrased it, here, makes clear my own view of the
answer.

In other words, having a sender give contingent -- in the sense that some
senders will give it and others won't -- directions about delivery is a very new
realm, not just for email but for Internet protocols in general.

Rather than cross over the line into that bit of architecturally experimental
specification, why is is not sufficient to leave things with the simpler --
albeit more passive -- stance that a sender talks about themselves but refrains
from telling the evaluator what to do with the information?  Yes, that is at
odds with a classic model of protocol specification, but we are juggling among
constraints, here.

d/
-- 

  Dave Crocker

---

From: <[email-masked]>
Date: Sun, 6 Aug 2006 19:13:06 -0400

Why not take an AIN approach? An SSP query to determine how to route the
message, with additional signatures, without and directly?
Thanks,
Bill

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Sunday, August 06, 2006 5:38 PM
To: [email-masked]
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy

>> If I choose to deliver unsigned mail that purports to be from a
domain that says
...

Mark,

I am a great fan of looking to the experience of the lower layers, when
trying
to develop mechanisms for applications, especially email.  So your
suggestion is
an important one to consider.

I think the problem is that email's variations in the handling of its
"packets"
make its environment too vastly different from the much simpler world of
IP.

(I'll skip over my recollection that there have been activities that do
partial
delivery on damaged IP datagrams. The standard says what you cite and it
is a
more useful place to start, I think.)

The question is whether we can get there with a directive, at this
point, in an
adjunct protocol that operates in the realm of a contingent, remote,
partially-adopted mechanism that changes the fundamentals of Internet
mail
delivery?

And, of course, the way I've phrased it, here, makes clear my own view
of the
answer.

In other words, having a sender give contingent -- in the sense that
some
senders will give it and others won't -- directions about delivery is a
very new
realm, not just for email but for Internet protocols in general.

Rather than cross over the line into that bit of architecturally
experimental
specification, why is is not sufficient to leave things with the simpler
--
albeit more passive -- stance that a sender talks about themselves but
refrains
from telling the evaluator what to do with the information?  Yes, that
is at
odds with a classic model of protocol specification, but we are juggling
among
constraints, here.

d/
-- 

  Dave Crocker

---

From: "william(at)elan.net" <[email-masked]>
Date: Sun, 6 Aug 2006 16:26:03 -0700 (PDT)

> message, with additional signatures, without and directly?

AIN?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: <[email-masked]>
Date: Sun, 6 Aug 2006 19:28:57 -0400

http://www.intel.com/network/csp/solutions/ngn/7643gls.htm
Advanced Intelligent Network (AIN)
The Advanced Intelligent Network (AIN) is a telephone network
architecture that separates service logic from switching equipment,
allowing new services to be added without having to redesign switches to
support new services. Developed by Bell Communications Research, AIN is
recognized as an industry standard in North America.

Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: william(at)elan.net [mailto:[email-masked]] 
Sent: Sunday, August 06, 2006 7:26 PM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]
Subject: RE: [ietf-dkim] "I sign everything" is not a useful policy

AIN?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 6 Aug 2006 23:09:06 -0400

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, August 06, 2006 5:37 PM
Subject: Re: [ietf-dkim] "I sign everything" is not a useful policy

> experimental specification, why is is not sufficient to leave things
> with the simpler -- albeit more passive -- stance that a sender talks
> about themselves but refrains from telling the evaluator what to do
> with the information?  Yes, that is at odds with a classic model of
> protocol specification, but we are juggling among
> constraints, here.

In my view, the power of DKIM-SSP is 100% about protocol consistency.  I
don't wish to be redundant, but this is how the DSAP introduction concludes:

[you may substitute DSAP for SSP]

   DSAP does not attempt to evaluate the reputation of the sender or
   client.  A good intention client can use DSAP as well as the bad
   intention client.  The main objective of DSAP is to establish a
   protocol consistency between all client types and to use the
   deviation from the consistency as part of a failure detection system

This is not different  than any other C/S negotiation handshake concept
such as with the PPP protocol where there is a LCP stage to negotiate the
link. If the expected link attributes are not met, the connection is not
made.

It was not different as with IEMSI (pronounced I-EM-SI) in the old fidonet
days where the common storage,  the NodeList (akin to DNS)  describes the
host server capabilities and attributes.  Both the client and server know
what was expected.

Similarly,  it is no different when an SMTP client calls a SMTP host and the
host exposes its EHLO capabilites which the client works with.  If the
client does something the server did not expect, we can presume there will
be some level of protocol inconsistency and failure.   But if the client
sends a fraudulent HELO or a RETURN PATH and the server doesn't check them,
well, then we have problems like we have today.

SSP Policies and attributes are defined by the owner in some common storage
we call DNS,  The owner uses them to create DKIM data. The verifier, if it
cares for security, which I presume it will,  will uses them to confirm the
DKIM data, if any.   If something is not quite kolsher, the natural
presumption is to assume a failure.

Now the real question here, is it practical?  Is it feasible?  It is doable?

For me, as a practioneer in the field,  I say yes.  It is possible and the
implementation code is really quite simple.

---

From: Damon <[email-masked]>
Date: Mon, 7 Aug 2006 10:13:15 -0400

+1

 I don't agree with everything in DSAP and would take you to task on one or two.
However, I believe that it is doable in our lifetimes and if we worked
really hard, could be worked out in this working session. Without it,
SSP's a big piece of duct tape.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Tue, 8 Aug 2006 11:01:41 -0400

Friends,
Let it never be said that I am inflexible and can't change my mind
from good arguments.

After a restless night thinking about this, I am going to change my
thoughts just slightly.

All email that has a munged sig or no sig that comes from an "I sign
all" domain should be expected not to reach its destination.

I want to see:

"I sign all" and/or these domains can sign for me. If the message is
not signed, it is expected by me that the messages will not reach its
destination.

"I sign none" Nothing from me at this domain should be signed. If it
is, it is expected by me that the message will not reach its
destination.

"I sign all" only from this domain(s) or _FDQN(s)_. Messages from this
domain(s) or FDQN(s) that are not signed are expected by me not to
reach their destination. However, messages coming from everywhere else
may or may not be signed. I expect that these messages will not be
effected under this policy.

I think that these policies should cover every scenario I can think of.

The FDQNs are important. As an admin who has several gateways at the
same domain, it would be nice to be able to route some mail fitting a
policy to a particular MTA to have it signed and delivered without
effecting my other mail.

If munging is too much of an issue, turn the policies off, fix the
problem, turn them back on. I don't think we should stop work just
because this _might_ happen. The benefits outweigh the risks.

Regards,
Damon Sauer

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Aug 2006 16:14:37 +0100

Again - this raises no new technical issue. So, let's please
wait and work on reqs-00's text,

Stephen.

---

From: Damon <[email-masked]>
Date: Tue, 8 Aug 2006 11:28:44 -0400

Soooo......

How's the weather?

Nice and HOT here in Atlanta :)

Damon

---

From: Frank Ellermann <[email-masked]>
Date: Tue, 08 Aug 2006 17:43:19 +0200

> Nice and HOT here in Atlanta :)

Okay in Hamburg.  No new IETF WGs in sight where questioning
a proposed MUST for an unpublished draft is off topic. <gd&r>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Aug 2006 16:55:22 +0100

> Okay in Hamburg.  No new IETF WGs in sight where questioning

...for the n-time...

> a proposed MUST for an unpublished draft is off topic. <gd&r>

Enough please,
S.

---

From: Damon <[email-masked]>
Date: Tue, 8 Aug 2006 16:08:37 -0400

> >> Since someone who doesn't sign anything wouldn't publish any keys, how
> >> could this possibly be useful?  Where would these rogue signatures
> >> come from, and how is a recipient going to verify a signature that has
> >> no key record?
> >
> > This was put in because I was reading threads where they wanted to be
> > able to say "I sign no mail". From what I read, this was for domains
> > that expliciately do not send _any_ mail what-so-ever.
>
> "I sign no mail" is quite different from "I send no mail."  The latter
> says to throw away unsigned mail.
>
> >> It should be obvious that "domain" and "FQDN" are exact synoyms in
> >> this discussion.  With that in mind, how does this differ from the
> >> first "I sign all"?  Nobody's going to be looking at your SSP for
> >> any domains other than yours.
> >
> > I do not see them as being exact but fdqn being a subset.
>
> In the DNS, a domain is a domain.  Subdomains are useful when you think
> about organizing your network, but when we're talking protocols, a query
> for dsl-467.podunk.someisp.com is no different from one for someisp.com.

It is if there is a policy record at dsl-467.podunk.someisp.com
I have some real life examples if you would like to see them.

>
> > For instance, all the messages I send come from the mta:
> > mail1.bigbank.com which are not signed and have a mail from: of
> > <employee>/at/bigbank.com except for my transactional messages. These
> > come from the mta: reciepts.bigbank.com which has a mail from:
> > customer_service/at/bigbank.com for which I want to apply the policy
> > of "I sign all" with the expected result of do not deliver anything
> > that is not signed.
>
> Please send that scenario in to the list so someone other than me can tell
> you that path authentication is completely off the table.
>
> If you want your transactional mail treated differently from your employee
> mail, put them in different domains, e.g.
> [email-masked].
>

This is *exactly* my problem with SSP. Without being able to state the
above, it makes it unwieldly. My example shows just one domain but
what if I have 132 peppered within these, 1 to 10 mta's some I would
want to sign for, some I would not. So now I would have to have all
email sent to postmaster/at/svc.bigbank.com forwarded to
postmaster/at/bigbank.com, plus every address that may be signing
mail.
 As an administrator, I would like the policy that says any time I
send to XYZ.com from bigbank.com due to a content policy or because
the email was sent between 3:15 and 3:17pm, whatever... I want to be
able to point that email at my "signing mta" and not break my
return-paths or add extra work for myself.

Why is it completely off the table?
I will let you send to the list if you'd like so that it is not
assumed that I am blindsiding you. :)
..on second thought... I will go ahead and post it. Since I feel this
_may_ be a new way of looking at the problem, I believe that it
follows Stephan's rules.

Damon

---

From: Damon <[email-masked]>
Date: Tue, 8 Aug 2006 17:03:06 -0400

> _may_ be a new way of looking at the problem, I believe that it

Or how about a useful example:

I run my eBay business out of my webmail account. I know that one of
the domains that I send to, for reasons of security or insanity,
requires that all email be signed. My webmail service does not want to
sign every piece of email that goes out the door, so they offer an
option in the form of a checkbox that says "sign this email". This
email is then diverted to a signing MTA which adds the sig. The policy
for _that_ mta is "I sign all mail". This is just a generic scenario,
but I have no doubt that something like this could be applied
somewhere quite usefully.

Damon

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 08 Aug 2006 22:50:03 +0100

This strikes me as more repetition. Please justify why its
not and/or recast it specifically addressing our requirements
draft.

We need to move beyond everyone's favorite idea of what's a
good idea and onto something that garners wider support.

Stephen.