Subject: RE: [ietf-dkim] The URL to my paper describing the DKIM policy options

From: "Patrick Peterson" <[email-masked]>
Date: Mon, 24 Jul 2006 22:27:39 -0700

> ----- Original Message -----
> From: "Hallam-Baker, Phillip" <[email-masked]>
> To: "IETF-DKIM" <[email-masked]>
> Sent: Wednesday, July 12, 2006 2:05 PM
> Subject: [ietf-dkim] The URL to my paper describing the DKIM 
> policy options
> 
> 
> I submitted the draft in both pdf and txt. Only the txt is 
> shown, the more
> readable pdf is attached.
> 
> http://www.ietf.org/internet-drafts/draft-hallambaker-pcon-00.txt

I think this is a great idea and am surprised it didn't generate more
traffic on the list. It's not easy to cram needed new functionality into
a backward-compatible solution.

pat

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

---

From: Douglas Otis <[email-masked]>
Date: Tue, 25 Jul 2006 07:56:02 -0700

> a backward-compatible solution.

This concept requires a wildcard PTR record at every label.  This
assumes there are no other PTR record used beyond reverse lookups, which
may not be the case.  Name errors would not be reported, which might
make other searches difficult and perhaps risk flooding caches with PTR
RRs.  This will also require special treatments at delegation points.

The intent was to point to a general label where policy references are
found.  Philip suggested this should point to an HTTP server.  HTTP is
needed to support the size of an all encompassing policy response.

If the PTR record can not be overlaid, then a new RR type is needed.
Defining a new RR type allows this RR type to be wildcarded at every
label and contain the policy information specific for a particular
protocol.  No multi-record lookup or HTTP would then be required. : )

Either way, it would be rather messy adding a RR at every node. If the
ultimate repository for this information is HTTP, it seems a protocol
using HTTP should be used instead. This HTTP service could locate all
the "registered" policy records.  Perhaps a few organizations would be
willing to provide a policy redirection service.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Tue, 25 Jul 2006 08:51:36 -0700

>a backward-compatible solution.
So I'm trying to understand the basic algorithm:

     To discover the policy for DKIM at alice.example.com: 
        
            1) policy = lookup (TXT, "_dkim.alice.example.com") 
                 IF policy <> NULL THEN RETURN policy 
             
            2) pointer = lookup (PTR, "alice.example.com") 
                 IF pointer == NULL THEN RETURN NULL 
             
            3) policy = lookup (TXT, "_dkim." + pointer) 
                 return policy 

So I set up mtcc.com's bind config to:

$ORIGIN mtcc.com.

*        IN     PTR    mtcc.com.

Where mtcc.com is the top level and contains the policy record. When I 
choose
a label that doesn't have any other labels (say, frogger.mtcc.com) it 
doesn't
return anything as TXT so I go to step 2, it points back to mtcc.com and 3
succeeds.

However, when I use a label *with* a record:
    fafner        IN    A    216.102.208.11

the host -t PTR fafner.mtcc.com returns a reply with an answer count of 
zero.
Which is just the same thing that happens with TXT.

So I guess I must be missing something because wildcarded PTR records seem
to be handled the same as any other wildcard which is to say, not the 
behavior
you'd hope for.

Phill?

       Mike

---

From: John Levine <[email-masked]>
Date: 25 Jul 2006 22:29:02 -0000

Phill's hack is indeed clever, but it seems to me egregiously
premature to propose a standard way to retrieve reputation data that
doesn't actually exist yet.  We could equally well come up with a rule
to map the selector to a URL which would work just as well albeit not
as fast, again to retrieve non-existent reputation info.

Let's finish the DKIM signature spec, then see if we can agree to get
out the smallest version of SSP on which we can get reasonable
agreement (probably two bits, one for signs everything, the other for
sends no mail), then we can return to the grand plans.

R's,
John

---

From: Arvel Hathcock <[email-masked]>
Date: Wed, 26 Jul 2006 10:03:25 -0500

> sends no mail), then we can return to the grand plans.

+1

The more I ponder this topic the more I'm inclined to believe that the 
flags "I sign everything" and "I don't send mail" are the base concerns 
that DKIM SSP must address.  I'm optimistic that, if one isn't 
fundamentally opposed to the entire SSP concept from the outset, we 
should be able to reach a consensus that this basic functionality is 
central to an SSP system that can do anything useful at all.

I think we've got a winner here -- and deliverable within a reasonable 
time frame -- if we can keep the core requirements to a minimum.

-- 
Arvel

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Jul 2006 16:30:15 +0100

> central to an SSP system that can do anything useful at all.

I've always wondered why dkim is taking on the task of supporting
"I don't send mail" since the statement makes no reference to
signatures at all. Arguably, that's something that should be dealt
with by someone else, who might also think about saying "I only
send mail that's less than 1MB", or, "I only send invoices".

If we do want SSP to allow the "I send no mail" statement then I
think we need to explicitly justify that being done here.

Just in contrast, a statement like "I sign no mail" would be much
more clearly within our scope. (Note: I'm not saying I prefer that
one, I just understand the scoping better.)

Stephen.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2006 08:26:51 -0700

> time frame -- if we can keep the core requirements to a minimum.

The gist of this sub-thread suggests that the requirements for an initial SSP
specification are simply:

1. It must be extensible (another IANA registry)

2. The initial set of practices that can be published receive quick, strong
support -- that is, clear rough consensus -- in the working group.  In other
words, if there appears to be any degree of concern, controversy or lack of
general interest in a feature, it should be immediately deferred.  (Deferred
does not mean ignored or dismissed.  It means deferred.)

d/

-- 

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

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Jul 2006 11:34:13 -0400

> time frame -- if we can keep the core requirements to a minimum.

As we think through the definition of minimum, I think it important that we 
consider the class of domains that are not supported by one or more dedicated 
mail servers.  Domains that send through shared servers are a large fraction 
of the domains in existence (although no doubt a much smaller fraction of 
e-mail being sent).

Is the concept of operations that these servers should sign using the 
provider's key (so all signatures for the domain are 3rd party) or that the 
provider should manage multiple keys to support per domain keys and sign the 
messages first party for the domain?

When one says 'signs all messages' does that mean first party signatures or 
any signature?  Announcing that all messages are signed, but may be signed by 
anybody, is trivially spoofable.

I understand and agree that we need to keep this to a minimum set of 
functionality to produce something useful, I believe that there is a 
irreduceable amount of complexity we need to consider.  I think it's better 
to work through it now and produce a simpler policy protocol.

Scott K

---

From: <[email-masked]>
Date: Wed, 26 Jul 2006 11:54:20 -0400

Scott,
I think that each domain would have a public key and the aggregator MTA
that is shared would sign on behalf of that domain
Jobob.com uses mx.isp.com to send mail
jobob.com would have a dns record containing public key information
mx.isp.com would sign using jobob.com keys.

Now conversely keeping jobob.com keys updated in a timely manner would
be time consuming so perhaps isp.com would have a policy that
I sign all mail 
And maintain a single record. This would be trivially spoofable until
the message hits the verifier which would then fail the signature.
Thanks,

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 Scott Kitterman
Sent: Wednesday, July 26, 2006 11:34 AM
To: [email-masked]
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options

> time frame -- if we can keep the core requirements to a minimum.

As we think through the definition of minimum, I think it important that
we 
consider the class of domains that are not supported by one or more
dedicated 
mail servers.  Domains that send through shared servers are a large
fraction 
of the domains in existence (although no doubt a much smaller fraction
of 
e-mail being sent).

Is the concept of operations that these servers should sign using the 
provider's key (so all signatures for the domain are 3rd party) or that
the 
provider should manage multiple keys to support per domain keys and sign
the 
messages first party for the domain?

When one says 'signs all messages' does that mean first party signatures
or 
any signature?  Announcing that all messages are signed, but may be
signed by 
anybody, is trivially spoofable.

I understand and agree that we need to keep this to a minimum set of 
functionality to produce something useful, I believe that there is a 
irreduceable amount of complexity we need to consider.  I think it's
better 
to work through it now and produce a simpler policy protocol.

Scott K

---

From: Mark Delany <[email-masked]>
Date: Wed, 26 Jul 2006 15:56:56 +0000

> send mail that's less than 1MB", or, "I only send invoices".

Especially since one can achieve that same effect by having an SSP
that says "I sign" everything and then don't sign any email.

Mark.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 26 Jul 2006 09:13:14 -0700

Stephen Farrell wrote:
> signatures at all. 

I suspect this is a good example of the confusion between describing the problem
domain DKIM is pursuing versus the mechanism DKIM defines, to deal with the
problem.

(There has been some tension about whether to describe DKIM merely in terms of
its cryptographic mechanism, or in terms of its larger goal. I think the point
you raise highlights the benefit of starting with the more general statement
that is independent of underlying technology.)

The problem domain is assurance of email authenticity -- that is, of an identity
associated with the message.  Signing is a mechanism for providing assurance.

If I say that I do not sent mail, but you get mail purporting to be from me,
then there is a pretty solid basis for believing the mail is not authentic.

Arguably, that's something that should be dealt
> send mail that's less than 1MB", or, "I only send invoices".

And this highlights the benefit of using a coarse filter on SSP details:  If
there is quick, broad agreement that the feature is useful, then add it now. If
the topic becomes complex -- that is, it will take some effort to agree on its
details -- then defer it.

My impression is that there is likely to be quick agreement on a binary flag
that says "The domain name administrator says that this domain name will not
appear in the rfc2822.From field, for any valid mail."  Whereas I suspect that a
more complex mechanism that specifies assorted contingencies is much less likely
to gain ready agreement.

d/
-- 

  Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Jul 2006 12:21:59 -0400

> the message hits the verifier which would then fail the signature.

And this is where there might be a complexity trade-off that is worth 
considering.

If our policy protocol gives jobob.com the ability to say "all mail is signed 
and the signer is isp.com" then the need for the added management complexity 
associated with multiple keys for multiple domains on the same host is 
mitigated.  

It is, of course, important to note that this would place a requirement on 
isp.com to ensure that messages it signed on behalf of jobob.com really were 
from jobob.com.  

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Jul 2006 11:14:08 -0700

This is a really good instance of what the base level requirements are.
On the one hand we can say that the requirement is that an ISP signing
on behalf of a customer actually sign on behalf of the customer. That
is, the d=customer.com rather than d=isp.com.

What I see here is the desire to actually have d=isp.com with the policy
saying that that is ok. One downside of this is that you'd require a policy
lookup because the From: address would still be customer.com, not
isp.com (ie, it looks like a third party). On the other hand, it doesn't
seem like it's a very big burden on the signing software to know what
domains it signs for, but I'm not as convinced about that from an
operational standpoint.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Jul 2006 14:46:51 -0400

> domains it signs for, but I'm not as convinced about that from an
Agreed.

I see it as a complexity tradeoff between managing multiple keys for multiple 
domains versus a single key for the ISP's domain and doing additional policy 
lookups for ISPs that sign 3rd party for their hosted domains.

In the short run a single key requires simpler software to execute and has 
fewer management headaches.  I think it is more deployable.  By substituting 
additional policy lookups for local key management and signing software 
complexity, the complexity is lower for the deployer.

In the long run the multiple key approach is probably more scalable since the 
associated complexities are within the boundary of the sending ISP and the 
part that has to scale to internet scale (the policy lookups) is minimized.

I do not think it likely that we can tell in the next several weeks which 
approach is the most likely to be utilized in the long run, so we ought to 
see if there is a reasonable way to accomodate both rather than pick.

As far as the burden associated with knowing which keys to use on a per-domain 
basis, I think there are two classes of burden:

1.  The back end management and coordination to get and maintain keys from all 
the relevant customers.

2.  The operation of the signing library that signs with a different key 
depending on the sender.

As far as how hard #2 is, does anyone's implementation support this currently 
(I'm asking, I don't know)?

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Jul 2006 11:47:48 -0700

> domains it signs for, but I'm not as convinced about that from an

By combining a designated signing domain list with that of a rather  
simply policy assertion, this does not involve an additional lookup.   
The only policy lookup would be from the customer.com domain where  
isp.com could be included within their designated signing domain  
list, when that is required by the policy asserted.  The policy could  
also indicate whether the list is open-ended or closed.  An empty  
closed list would indicate only customer.com could produce a valid  
signature for the OA.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 26 Jul 2006 15:13:52 -0400

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, July 26, 2006 11:30 AM
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options

> send mail that's less than 1MB", or, "I only send invoices".

A "No Mail Expected" policy is going to very powerful policy for domains
where mail is never expected.   You find this now with SPF. Altavista.com
has a "Alway Reject" policy.

     "All mail claiming to be from altavista.com is forged"
     "v=spf1 +exists:CL.%{i}.FR.%{s}.HE.%{h}.null.spf.altavista.com -all"
     "This domain sends no email"
     "Null SPF is for tracking purposes only"

> one, I just understand the scoping better.)

The two are different.

With no signature existing, you will always need to check the SSP in order
to check for a "Always Sign" or "We don't send mail from domain. Its
Forged." expectation.

With a signature existing, you will always need to check the SSP in order to
check for a "Never Sign" or "We don't send mail from domain. Its Forged"
expectation.

So you always need to check for SSP first.

I don't think you should eliminate the 3rd party signature potential, but I
can see where you might have a BASE SSP draft designed for Original Domain
expectations versus a 3PS SSP Draft higher layer that supports the BASE SSP
with new 3PS logic as well.

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

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 Jul 2006 12:26:54 -0700

>      "Null SPF is for tracking purposes only"

"MX 0 ." seems to be the standard way of asserting that a domain
neither sends nor receives email. Shoehorning the same assertion
into multiple different pseudo-standards simply leads to contradiction.

I don't see why people would pay any more attention to an SSP
statement of such than they do to SPF statements of it. Just the
opposite, shoehorning unneeded cruft into SSP makes it less likely
that people will pay any attention to it, I'd think.

Cheers,
   Steve

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Jul 2006 15:43:40 -0400

On Wednesday 26 July 2006 15:26, Steve Atkins wrote:

> neither sends nor receives email. 

It is a way that people do it.  AFAIK, there is no standard that describe that 
assertion.

Scott K

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 26 Jul 2006 12:50:15 -0700 (PDT)

On Wed, 26 Jul 2006, Scott Kitterman wrote:

> It is a way that people do it.  AFAIK, there is no standard that 
> describe that assertion.

What does assertion that I can not receive emails addressed to (based
on RFC2821 session RCPT TO) a.com have to do with assertion that I 
do not send any email with header field line "From: <address>@a.com"?

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 26 Jul 2006 16:04:41 -0400

----- Original Message -----
From: "Steve Atkins" <[email-masked]>

> into multiple different pseudo-standards simply leads to contradiction.

MX is about INBOUND. Not Outbound Mail.  That would only cover a possible
"no don't receive mail" policy. But I doubt this MX 0 is widely supported.
The attempts I have researched shows very low usage and if found, it is
mixed used with other non MX 0 statements.  I hope this does not begin to
chip away at SSP.

> that people will pay any attention to it, I'd think.

Steve, the SPF example was just an example to Stephen, that such a "No
(Outbound) Mail expected" concept does exist and is used in practice.  If
AltaVista.com can do it, so can others.   I can tell you that we will add a
NO MAIL POLICY to atleast 3-4 of our own domains if SSP was to become part a
new wide adopted practice.   We have no problem protecting local policy when
the spoofs come out way.  It is to expose to the external world not to
expect and accept such spoofs.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Jul 2006 16:08:32 -0400

> do not send any email with header field line "From: <address>@a.com"?

It doesn't, but there are proponents of the idea that it should.  Bad idea in 
my book, but there are proponents.  They key point is that even if that were 
a common usage, there is no standard that defines it.  

AFAIK, the only standard that allows an existing domain to assert it sends no 
mail is the SPF RFC, RFC 4408, and that is experimental.  There is still no 
standards track method to assert "sends no mail".  

Scott K

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Jul 2006 21:24:01 +0100

Hector,

Hector Santos wrote:
> (Outbound) Mail expected" concept does exist and is used in practice.  

Thanks for that. I do understand the reasoning behind the requirement,
but I don't understand the logic of why it should be addressed by SSP
as opposed to say SPF or whatever.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 26 Jul 2006 21:24:57 +0100

> that says "I sign" everything and then don't sign any email.

Hey a one bit policy! Now that I like :-)

S.

---

From: Steve Atkins <[email-masked]>
Date: Wed, 26 Jul 2006 13:28:07 -0700

On Jul 26, 2006, at 1:04 PM, Hector Santos wrote:

> AltaVista.com can do it, so can others.

     [steve@goliath steve]$ host -t mx altavista.com
     altavista.com mail is handled by 0 .

My point exactly. But even ignoring that option and just
comparing to SPF...

> I can tell you that we will add a

There is no need to tie "signing of email" to "this domain
sends no email". As such it's not something that _has_ to
be in SSP (unlike "We send no non-signed email"). If you
believe SSP has value you pretty much have to believe
the same of SPF, and SPF already supports making that
statement.

So the only advantage of supporting "we send no mail"
in SSP would be if you believe that the set of people who
look at SSP and do not look at SPF is noticably non-zero.

That's not a reason not to add support for this to SSP, though,
as long as you recognize that it's just adding a redundant
way of saying the same thing at the cost of a small increase
in complexity and risk of contradictory policy messages
via different communication channels.

Cheers,
   Steve

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Jul 2006 13:34:06 -0700

> with new 3PS logic as well.

DKIM makes administration of designated signing domains difficult  
because Selectors are not deterministic.  Listing these designations  
represents an easier means to manage this relationship and provides a  
method of stating policy.

The following should represent fairly complete policy at the OA domain:

1- A Designated Signing Domain List
2- A Flag indicating whether DSDL is open-ended or closed.

Meaning derived:

Empty open-ended DSDL
  - Other domains handle the OA (default without policy asserted)

Empty closed-ended DSDL
  - No domain handles the OA (no mail sent from here)

Populated open-ended DSDL
  - Listed domains handle the OA as "first-party"
  - Other domains handle the OA.

Populated closed-ended DSDL
  - Listed domains handle the OA as "first-party"
  - No other domains handle the OA.

Other domains handling the OA may or may not sign using DKIM.

A policy (a flag) combined with a Designated Signing Domain List can  
be achieved within one query, whether this is a TXT RR, a TXT + PTR  
RRset, or a DKIM POLICY specific RR.  The DSDL itself along with one  
simple flag indicating whether it is open-ended or closed DSDL  
provides all policy that should be needed.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Jul 2006 13:36:52 -0700

>lookups for ISPs that sign 3rd party for their hosted domains.

I think the issue of multiple keys is orthogonal as you could use one
key in either scenario. My code, for example, currently supports either
key scenario: one key for multiple domains, different keys for different
domains, etc. I think the issue is whether the signer needs to keep track
of all the domains it signs for or not. It seems to me that it would though,
and if that's the case I'm not sure if it's worthwhile having indirection at
the policy layer instead of just doing at the signing layer.

>(I'm asking, I don't know)?

Mine supports #2, and it wasn't all that complicated. Scaling it up to
thousands of domains  would probably take some extra work for a
better data structure, but that's a pretty well understood problem.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Jul 2006 16:47:08 -0400

> via different communication channels.
It might be useful (later, after the requirements discussion is complete) to 
explore the feasibility of a common policy record for the two for future 
revisions.  The risk associated with complexity and the possibility of 
contradictory policy statements may make the associated up front pain 
worthwhile.

I would imagine that 'the market' is looking for simplicity in a holistic 
approach.  The more that these technologies can be effectively integrated, 
the better off the average mail admin will be.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 26 Jul 2006 17:26:05 -0400

----- Original Message -----
From: "Steve Atkins" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, July 26, 2006 4:28 PM
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options

> via different communication channels.

I'm sorry, did you think I was suggesting to add SPF to the DKIM/SSP mix?

If so, I was not.  I think DKIM/SSP should be an independent payload
technology with only one common ingredient 822/2822 + DNS and for the most
part 821/2821.

How ISV and operators will augment separate ideas is up to them.
AltaVista.com illustrates this with support for SPF and MX 0 to cover a "No
Outbound Mail Expected" and a "No Inbound Mail Expected" policy,
respectively.

Keep in mind that the current SSP checks calls for only checking an SSP iff
the signature fails.  Although, I believe the more efficient model for the
verifier who will need to deal with the DKIM blitz of high potential
failures is to check for SSP immediately, I suggested that this logic be
changed, at a minimum, to a failed 3rd party signature.  But that could be
an ISV implementator detail and not necessary part of the specs.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 26 Jul 2006 17:41:33 -0400

On Wednesday 26 July 2006 16:36, Michael Thomas wrote:
> >>saying that that is ok. One downside of this is that you'd require a
> >> policy lookup because the From: address would still be customer.com, not
> >I see it as a complexity tradeoff between managing multiple keys for
> > multiple domains versus a single key for the ISP's domain and doing
> > additional policy lookups for ISPs that sign 3rd party for their hosted
> > domains.
>
> of all the domains it signs for or not. It seems to me that it would
> though, and if that's the case I'm not sure if it's worthwhile having
> indirection at the policy layer instead of just doing at the signing layer.
>
It would also have to determine if, in fact, a message it was signing for a 
domain was actually from an authorized sender for that domain (a requirement 
no matter how this beast gets killed).

I don't know how detailed the requirements document you are working on is 
intended to be....

At a high level, I think it is a requirement that the DKIM with a sender 
policy protocol support the use case of multiple administratively separate 
domains sending signed mail via a shared (e.g. ISP) server.

This has several lower level requirements that I can think of offhand for the 
signer:

 - Ensuring that messages that are signed for a domain are from an authorized 
source for that domain.

 - Signing the message in a way that allows receivers to know that the 
signature is an authorized signature for the sending domain (and this could 
be first party using one or more keys or 3rd party with a policy record that 
indicates that the signer is authorized)

 - Public or Public/Private (depending on how the previous requirement is 
satisfied) key exchange and maintenance.

The domain owner will have to publish the key and possibly  a policy record in 
their DNS.

Scott K

---

From: <[email-masked]>
Date: Wed, 26 Jul 2006 18:51:31 -0400

Scott,
I don't know if you have looked at Hector Santos policy document, he
does a very good job of assigning values and tags that define needed
policies.

http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html
http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.txt

we should all take a look, some good ideas in there.
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 Scott Kitterman
Sent: Wednesday, July 26, 2006 5:42 PM
To: [email-masked]
Subject: Re: [ietf-dkim] requirements

> indirection at the policy layer instead of just doing at the signing
layer.
It would also have to determine if, in fact, a message it was signing
for a 
domain was actually from an authorized sender for that domain (a
requirement 
no matter how this beast gets killed).

I don't know how detailed the requirements document you are working on
is 
intended to be....

policy protocol support the use case of multiple administratively
separate 
domains sending signed mail via a shared (e.g. ISP) server.

This has several lower level requirements that I can think of offhand
for the 
signer:

 - Ensuring that messages that are signed for a domain are from an
authorized 
source for that domain.

 - Signing the message in a way that allows receivers to know that the 
signature is an authorized signature for the sending domain (and this
could 
be first party using one or more keys or 3rd party with a policy record
that 
indicates that the signer is authorized)

 - Public or Public/Private (depending on how the previous requirement
is 
satisfied) key exchange and maintenance.

The domain owner will have to publish the key and possibly  a policy
record in 
their DNS.

Scott K

---

From: Michael Thomas <[email-masked]>
Date: Wed, 26 Jul 2006 17:44:42 -0700

>I don't know how detailed the requirements document you are working on is 

I think it needs to be detailed enough that we capture the high level
uses and their implications, but no more.

>satisfied) key exchange and maintenance.

I think these are largely captured in dkim-base or the -threats 

>The domain owner will have to publish the key and possibly  a policy record in 
In thinking more about both your and Bill's comments it occurs to me 
there is
another advantage of the policy indirection that was being discussed: if an
ISP signs for a bunch of domains and decided that it needed to change a
signing key, that key would need to be updated in all of the DNS zones
it signs for which may be quite painful.

This could possibly be dealt with in a couple of ways:

1) make all of the customer's zones change (bletch).
2) customer delegates the _domainkey subdomain to the provider so they
    can manage it on the customer's behalf (probably only scales to one 
provider
    though)
3) have the ability for the policy statement say that a provider(s) 
legitimately
    signs for that domain.

(2) puts the responsibility for management of the zone on the email 
service provider
which may not be very natural. (3) has scaling issues transport if there 
were to be
more than one entity allowed to sign for a domain, which seems like a 
likely use
case too.

There may be ways to tease these use cases apart though. I'm sort of 
inclined to
put (3) in the requirements to capture the issue even if we ultimately 
decide that
it's not a good idea and abandon it.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 26 Jul 2006 18:15:52 -0700

+1

Ways 1 and 2 should be fairly transparent from a policy standpoint,  
but these methods likely represent an ongoing expense.  Way 3 could  
be done by most with minimal effort or interaction with the signing  
domain.  By decreasing the expense, Way 3 should also increase DKIM  
adoption.

-Doug

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 27 Jul 2006 03:02:55 -0500

> that says "I sign" everything and then don't sign any email.

One can achieve the same effect perhaps but it's not as easy to 
understand or explain:

Potential customer question: "How do I communicate that I don't send mail?"

Answer: "You imply in your policy that, in fact, you do send mail, that 
all such mail must be signed, but then because there won't be any 
signatures you'll achieve your goal."

Customer scratches head: "Why not just a binary flag that says 'I don't 
send mail'?"

-- 
Arvel

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 27 Jul 2006 03:44:23 -0500

> 2.  The operation of the signing library that signs with a different
 > key depending on the sender.
 >
 > As far as how hard #2 is, does anyone's implementation support this
 > currently (I'm asking, I don't know)?

Yes, MDaemon does.  We found this to be a necessity so I created the 
ability to assign selectors and d= values based on criteria present 
within a message eligible for signing.  It wasn't difficult.  The only 
problem will be if there were thousands of selectors because our GUI 
interface will need to be improved.

-- 
Arvel

---

From: Mark Delany <[email-masked]>
Date: Thu, 27 Jul 2006 09:09:45 +0000

> Customer scratches head: "Why not just a binary flag that says 'I don't 

So it could be an alias entry in SSP then. One is called "I sign all"
and the other is called "I don't send". They both set the same bit.

Besidewhich wont a UI hide the nitty gritty of what bits are set
where?

But you know, whatever. If people want a two-bit solution for a
one-bit problem. That's ok :-)

Mark.

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 27 Jul 2006 03:28:58 -0500

> "I don't send mail" since the statement makes no reference to

Here's my own view.  DKIM is not only (or merely) the mechanics of 
digital signature construction and verification.  Signatures are just a 
tool -- a safe way of saying "I insert X so is X present?" (X being, in 
our case, a DKIM signature).  The primary goal however is not to 
construct signatures.  We want to make improvements in the email 
authenticity space.  Another vector for that might be "I don't send 
mail".  That this doesn't directly involve signatures is not in the 
least a problem.

-- 
Arvel

---

From: wayne <[email-masked]>
Date: Thu, 27 Jul 2006 12:09:28 -0500

In <[email-masked]> Steve Atkins <[email-masked]> writes:

>> [mention of the SPF record "v=spf1 -all" as a "we never send email"
>> notification]
>

"MX 0 .", like all MX records with bogus mail exchanges, in effect
says "I can not receive email".  This is not quite the same as saying
"I do not send email".

First off, the "MX 0 ." technique will cause queries asking the root
for A records, which don't exist.  The root servers already get enough
bogus queries, it doesn't seem like a good idea to promote a technique
that makes things worse.

Secondly, I have several domains that, while they never *send* email,
I do want to receive email for them.  Some of these domains are stuff
that used to be in use, pass on obsolete email addresses on to the
correct (newer) domain or are used as spam traps.  However, others are
because I want to allow abuse reports for websites.

There are people who argue that any host that doesn't accept an
abuse@host email is in violation of RFC2142 and will block email from
these domains, even if that domain is used in the 2821.HELO address
rather than the 2821.MAILFROM or 2822.From: address.  See
rfc-ignorant.org for an example.

So, I think the SPF record "v=spf1 -all" is much better than using
"MX 0 .".

> that people will pay any attention to it, I'd think.

The SPF record "v=spf1 -all" case can be safely used to reject
connections for both the 2821.HELO and 2822.MAILFROM during the SMTP
session without any of the failure cases of other SPF records.  That
is, there are no problems with forwarding and such.

I can see similar uses for a DKIM policy, although I can also see the
argument that having yet another way of saying the same thing is not a
particularly good idea.

-wayne

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 27 Jul 2006 18:20:58 +0100

Douglas Otis wrote:
> 
> On Jul 27, 2006, at 2:09 AM, Mark Delany wrote:
> There is a slight difference between these two scenarios.  This 
> difference between "All Signed" and "Don't Send" becomes significant 
> when deciding what to do with an invalid signature.

Prsumably only if the domain published some key for some selector
though which I guess you'd only do if you actually do sign something
(or have crazy s/w that creates keys without saying so:-).

But we've probably fixated on this enough for Mike to have plenty of
options for writing 1st cut reqs text.

What other (sorts of) requirements have not yet been brought up?

S.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jul 2006 10:54:46 -0700

On Jul 27, 2006, at 10:20 AM, Stephen Farrell wrote:

>>> So it could be an alias entry in SSP then. One is called "I sign  
>>> all" and the other is called "I don't send". They both set the  
>>> same bit.
>>
>> difference between "All Signed" and "Don't Send" becomes  
>> significant when deciding what to do with an invalid signature.
>
> Presumably only if the domain published some key for some selector  
> though which I guess you'd only do if you actually do sign  
> something (or have crazy s/w that creates keys without saying so:-).

Not finding a key represents a PERMFAIL (no key for signature).  Both  
no key and PERMFAIL are due to several causes, where the Base draft  
does not indicate that there be special handling resolving even  
PERMFAIL.

DKIM Base:
,---
|6.1  Extract Signatures from the Message
|...
| In the following description, text reading "return status
| (explanation)" (where "status" is one of "PERMFAIL" or "TEMPFAIL")
| means that the verifier MUST immediately cease processing that
| signature.  The verifier SHOULD proceed to the next signature, if any
| is present, and completely ignore the bad signature.
'___

This statement clearly places invalid signatures into one pile, key  
or no key.  If there is a desire to special case specific conditions  
leading to PERMFAIL, then policy seems a good place to make this  
resolution explicit.

-Doug

---

From: <[email-masked]>
Date: Thu, 27 Jul 2006 14:00:11 -0400

My requirements

I sign all
I sign nothing
I sign only 3rd party
I sign all and 3rd party
I sign some mail

My Policy/Practice

I sign all - every piece of mail purported to be from me must be signed

I sign nothing - If mail arrives with a DKIM sig I didn't send it

I sign only 3rd party - I only act as a signing domain for other
domains, I don't sign any of my own mail 

I sign all and 3rd party- I sign all my mail and for other parties as
well

I sign some mail - I sign only mail that I am willing to swear that I am
responsible for

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 Stephen Farrell
Sent: Thursday, July 27, 2006 1:21 PM
To: Douglas Otis
Cc: [email-masked]
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options

S.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jul 2006 11:20:19 -0700

> I sign some mail

A designated signing domain list declared as open or closed would  
practically fulfill these requirements while also being explicit.   
There should be a distinction made between a designated signing  
domain and a non-designated (unknown third-party signing domain or  
"other").  "I sign only 3rd party" policy is obtained from the OA  
domain so this should be restated as:

"These are the signing parties (excluding my domain)"

"I sign all"
DSDL: <cox.com>
list-mode: closed

"I sign nothing"
DSDL: <>
list-mode: closed

"I sign only 3rd party"  Policy is obtained from the OA domain so  
this should be restated into:

"These are the signing parties (excluding my domain)"
DSDL: <example.com>
       <example.org>
       <someother.domain>
list-mode: closed

"These are the signing parties (including my domain)"
DSDL: <cox.com>
       <example.com>
       <example.org>
       <someother.domain>
list-mode: closed

"I sign some mail"
DSDL: <cox.com>
list-mode: open

As stated earlier, this name list approach may also offers benefits  
when evaluating the message envelope.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Jul 2006 11:26:07 -0700

>I sign some mail - I sign only mail that I am willing to swear that I am

I am completely confused by "I sign nothing" and "I sign only 3rd 
party" and "I sign some mail". I don't see the value of those to the 
recipient.

"I sign nothing" seems weird. If I have something signed by your 
domain, and I cannot get the signing key from your domain, "I sign 
nothing" adds no value. The signature is invalid. If an attacker can 
inject a DKIM header and a key, he can also suppress the SSP response.

"I sign only 3rd party" has the same attack problem as "I sign nothing".

"I sign some mail" doesn't tell the recipient anything useful.

What am I missing?

--Paul Hoffman

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 27 Jul 2006 14:54:27 -0400

> I sign all - every piece of mail purported to be from me must be signed
Must be signed by you are must be signed by anybody.  If the latter, it's 
trivially spoofable unless you have a list of others that are authorized to 
sign.

Scott K

---

From: wayne <[email-masked]>
Date: Thu, 27 Jul 2006 14:08:55 -0500

> "I sign some mail" doesn't tell the recipient anything useful.

It says that you should look at email without a signature as being
"acceptable", unlike a "I sign all mail" which without a signature is
quite questionable.

-wayne

---

From: Steve Atkins <[email-masked]>
Date: Thu, 27 Jul 2006 12:17:32 -0700

> "acceptable", unlike a "I sign all mail" which without a signature is

How does that differ from a sender that doesn't have the
"I sign some mail" flag set?

Cheers,
   Steve

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Jul 2006 12:19:07 -0700

>"acceptable", unlike a "I sign all mail" which without a signature is
 From what I can tell, "I sign some mail" tells the receiver that the signer
wants to put up a policy statement, but that's about it. The one thing 
that's
vaguely interesting about this is that we could do surveys of who's at
least thinking about dkim.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jul 2006 12:42:12 -0700

On Jul 27, 2006, at 12:19 PM, Michael Thomas wrote:
>> "acceptable", unlike a "I sign all mail" which without a signature  
>> is quite questionable.
>
> From what I can tell, "I sign some mail" tells the receiver that  
> the signer wants to put up a policy statement, but that's about it.  
> The one thing that's vaguely interesting about this is that we  
> could do surveys of who's at least thinking about dkim.

The "I sign some mail" (an open-ended list) also indicates that when  
a signature is damaged by a mail-list for example, this source should  
be considered valid for their OA.  An open-ended list also allows  
positive annotations, but with fewer delivery failures or support calls.

-Doug

---

From: wayne <[email-masked]>
Date: Thu, 27 Jul 2006 14:45:15 -0500

> "I sign some mail" flag set?

heh.  I knew as soon as I posted my too-short email that I would get a
reply like this.  I was in the process of composing a reply to myself
when yours came in.

Yes, signatures will be broken in transit and it will be a long time
before people can very safely reject email based on not having a valid
signature, even if you have an "I sign everything" policy.  This is
why I said that it is only "questionable", not "rejectable".

However, an "I sign everything" policy still gives a lot of important
clues.

First, a lot of spam and email worms will not have any signature, just
because it takes more work to do.  Email that gets broken in transit
will still have a valid selector and such, and that selector is going
to vary quite a bit between domains.  It isn't trivial to just throw a
signature into your spam/worm that appears to have been broken in
transit.

Secondly, the there is going to be a fair amount of consistency about
which MTAs will send you email with broken signatures and which
won't.  You can develop a list of mailing lists and such that are
known to break signatures, and you can combine that with existing
lists of known spam sources.  Combining the two, you can find
determine which email is likely legitimate and which is likely spam
and put that into your spam scoring system.

As time goes on and more people clean up their email and stop breaking
things in transit, this technique is going to become easier and more
reliable. 

Lastly, there are some domains that can implement an "I sign
everything" policy much easier than others.  A bank might well be able
to say that *no one* should send email through any other sources other
than their approved MTAs.  You can't use your ISP if you are working
at home, you can't use webmail.  It is a firable offense.   Other
domains simply can not force such policies on their users any time in
the foreseeable future; ISPs and webmail providers spring to mind.

I think there are also going to be some domains that only sign, and
thus risk their reputation on, some email, but not all of it.  You
can, say, sign all transactional email, but not sign stuff from the
marketing department.  Or, an ISP could only sign email that gets a
good grade on their outgoing spam filter system.

So, I do think that some value can be extracted from the distinction
between an "I sign everything" policy with an "I sign some email"
policy.

-wayne

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Jul 2006 12:53:40 -0700

Douglas Otis wrote:

>> From what I can tell, "I sign some mail" tells the receiver that  the 
>> signer wants to put up a policy statement, but that's about it.  The 
>> one thing that's vaguely interesting about this is that we  could do 
>> surveys of who's at least thinking about dkim.
>
>

I have no idea what an "OA" or "open ended list" is, but I seriously 
doubt it. Preferential treatment
based on unverifyable DKIM-Signature bits is an invitation for abuse.

       Mike

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Jul 2006 12:59:19 -0700

>"I sign some mail" flag set?

Yes, exactly.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jul 2006 10:01:23 -0700

On Jul 27, 2006, at 2:09 AM, Mark Delany wrote:
>>> Especially since one can achieve that same effect by having an  
>>> SSP that says "I sign" everything and then don't sign any email.
>>
>> Answer: "You imply in your policy that, in fact, you do send mail,  
>> that all such mail must be signed, but then because there won't be  
>> any signatures you'll achieve your goal."
>>
>> Customer scratches head: "Why not just a binary flag that says 'I  
>> don't send mail'?"
>
> all" and the other is called "I don't send". They both set the same  
> bit.

A designated signing domain list with a single bit indicating whether  
the list is open-ended provides for both "All Signed" or "Don't  
Send".  The designated signing domain list might also validate  
relationships beyond the OA during the envelope examination phase,  
for example.

EHLO hostx.dkim-signer.org

MAIL FROM: [email-masked]
...

From: Joe Sixpack <[email-masked]>
DKIM-Signature: <... d=dkim-signer.org>

EXAMPLE.COM policy
  DSDL:
   DKIM-SIGN
   BIG-ISP
   EXAMPLE.COM

  List-mode: Closed

Finding an address for either the EHLO or a REVERSE DNS host name is  
a fairly common first step.
The DSD list offers a means to confirm relationships between more  
elements than just the OA and achieve "All signed" or "Don't Send"  
with a single bit.  When the List-mode is Open, then unlisted,  
broken, or non-signed messages may be associated with the OA and  
certainly other message elements.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jul 2006 12:13:10 -0700

Scott Kitterman wrote:
> mail servers.  ...

Why should it matter whether the host is shared, or not?  The question of
whether to have the provider do the signer or whether to have a content agent
(rfc2822.From or rfc2822.Sender) strikes me as important generally, not just
when the provider has more than one user domain sending from the provider's
platform.

The essential question is whose reputation (accreditation, certification, etc.)
is to be used.  It might well be that there should be a signature by EACH of the
relevant domains, in order to call on reputation information both for the author
as well as for the originating provider.

d/

-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Thu, 27 Jul 2006 12:04:34 -0700

> one-bit problem. That's ok :-)

Well, no, It really isn't.

For example, it leads to multiple ways of doing the same thing, which at least
leads to increased system complexity and often leads to ambiguity, which kills
interoperability.

Besides that, your raising the distinction between the underlying encoding,
versus the way the information is presented to users (including system
administrators) is a a fundamental point. People often confuse the two.

And lastly, when a protocol design tends to treat each item as independent, even
when two or more really are the same (or are mild variations of each other) then
the entire protocol tends to devolve into an mass of special-cased behavior,
rather than having any sort of cohesive framework.

So, no, it really is not ok.

d/

-- 

  Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 27 Jul 2006 16:59:48 -0400

On Thursday 27 July 2006 15:13, Dave Crocker wrote:
> > we consider the class of domains that are not supported by one or more
> > dedicated mail servers.  ...
> > the provider should manage multiple keys to support per domain keys and
> > sign the messages first party for the domain?
>
> whether to have the provider do the signer or whether to have a content
> agent (rfc2822.From or rfc2822.Sender) strikes me as important generally,
> not just when the provider has more than one user domain sending from the
> provider's platform.
>
If I send mail through the mail server of isp.example.com and they sign with 
my key, it matters a GREAT deal to me if they also sign other people using my 
name with my key.  This may be largely an operational question, but the 
protocols have to support getting a reliable answer to it.

You are correct that there are some broader questions buried in here, but the 
shared server scenario is probably the most complex common use case and I 
think it important that we support it.

> The essential question is whose reputation (accreditation, certification,
> etc.) is to be used.  It might well be that there should be a signature by
> EACH of the relevant domains, in order to call on reputation information
> both for the author as well as for the originating provider.

No.  The question for this policy discussion is who's policy gets used, how is 
it interpreted and finally ... lets make sure that messages don't get 
attributed to the wrong domain for reputation, etc. purposes.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jul 2006 13:58:56 -0700

On Jul 27, 2006, at 12:53 PM, Michael Thomas wrote:

> Douglas Otis wrote:
>>
>> The "I sign some mail" (an open-ended list) also indicates that  
>> when  a signature is damaged by a mail-list for example, this  
>> source should  be considered valid for their OA.  An open-ended  
>> list also allows  positive annotations, but with fewer delivery  
>> failures or support calls.
>
> I have no idea what an "OA" or "open ended list" is, but I  
> seriously doubt it. Preferential treatment based on unverifyable  
> DKIM-Signature bits is an invitation for abuse.

OA was short-hand for Originator Address (OA) as defined in Eric  
Allman's SSP draft.  This OA, or perhaps the Signing Address (SA) as  
defined thin the Base draft, would be where a DKIM related policy  
might be found.

While DNS zone delegations are possible, these require formal  
arrangements, rather than less formal arrangements currently common  
place when using an ISP for outbound traffic.  This ISP might now  
employ DKIM signing under their domain.  The existence of the DKIM  
signature offers a valuable tool for combating abuse, where much of  
this value would be unrelated to an OA or SA policy assertion.  The  
concerns related to the OA or SA are likely important to a minority  
of DKIM signing domains being spoofed, especially when an exacting  
assertion leads to a delivery failure.

To permit less formalized arrangements between OAs or SAs and an ISP  
offering DKIM signing under their domain, DKIM policy could be  
defined as just being a list of designated signing domains for the OA  
or SA.  This list could have two modes.  One mode could then be  
defined as being "open-ended" which means the list is not complete.   
A list that is not "open-ended" would be "closed-ended" or "fixed."   
A "close-ended" list indicates that the OA or SA has declared an  
explicit set of valid signing domains.  A designated signing domain  
list (DSDL) and a single flag indicating open or closed permits every  
policy required by Bill, for example.

Perhaps another major benefit from this approach would be improved  
envelope handling when a greater range of associations are made  
possible.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Jul 2006 14:57:51 -0700

>protocols have to support getting a reliable answer to it.
I think I detect some old world thinking here. This is certainly the 
case with
IP addresses, but don't see why it need be the cae with crypto. If the name
bound to a particular key doesn't do bad things, that really doesn't say 
anything
about another name bound to the same key. Both identities can and probably
should accrue their reputations independently. Only after you had sufficient
evidence might it be a good idea to make an induction about a new identity
bound to that key.

In any case, DKIM allows either mode so I'm not sure what the problem is
here.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 27 Jul 2006 18:15:48 -0400

> >If I send mail through the mail server of isp.example.com and they sign
> > with my key, it matters a GREAT deal to me if they also sign other people
> > using my name with my key.  This may be largely an operational question,
> > but the protocols have to support getting a reliable answer to it.
>
> should accrue their reputations independently. Only after you had
> sufficient evidence might it be a good idea to make an induction about a
> new identity bound to that key.
>
It's more the other way around I'm worried about.

If I use isp.example.com and they sign messages with my name and a key (theirs 
or mine, doesn't matter) and they also sign messages actually sent by joe 
spammer (another one of their customers) with my name and a key (again, 
theirs or mine), then it sucks to be me.  That's the problem.

This is really an internal ISP operational problem (they need to sort out who 
is allowed to use what identities on their servers), but the protocol and 
associated guidance need to make that clear.  

Scott K

---

From: Jon Callas <[email-masked]>
Date: Thu, 27 Jul 2006 15:23:28 -0700

> protocols have to support getting a reliable answer to it.

It isn't your key. It is example.com's key. They *may* mark your name  
in an i= option, but they may not. The i= field is really something  
that the administrative domain puts in for its own purposes (which  
may very well tick you off).

	Jon

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Jul 2006 15:29:20 -0700

>theirs or mine), then it sucks to be me.  That's the problem.
I'm confused: if your ISP is signing on your behalf and doesn't have any
access control to make sure it's really you, that sounds like good reason
to shop for a new ISP that does.

>associated guidance need to make that clear.  
The -base document has text about the need for access control.

       Mike

---

From: Jon Callas <[email-masked]>
Date: Thu, 27 Jul 2006 15:31:26 -0700

> theirs or mine), then it sucks to be me.  That's the problem.

No, it doesn't suck to be you. The first letter of DKIM stands for  
"Domain." It sucks to be example.com.

The DKIM signature is a statement by the administrative domain that  
it accepts responsibility for the message. It doesn't say anything  
about you.

One of the features of DKIM is that your domain is standing up for  
you, the end user. You're just a user.

Now then, there are some issues that do affect you. Some  
administrative domains (pick any big one: Yahoo!, AOL, Gmail,  
Wanadoo, etc.) will be large enough that statistical effects happen.  
For example, if you get enough users in a domain, statistically, at  
least one will be a bad actor. That will tend to lower the reputation  
etc. of the domain.

Some small domains (I'm sending from one) are unlikely to have bad  
actors. Note that I said unlikely. It's still possible, even if I am  
the only user in my domain that I'll get hacked and some malware will  
send something untoward. That has consequences.

> associated guidance need to make that clear.

How is it not clear now?

	Jon

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Jul 2006 15:40:29 -0700

>    can manage it on the customer's behalf (probably only scales to one
Actually, the multiple-provider case is one of the situations supported
by the "dotted selector" mechanism:  the customer can delegate the zone
foo._domainkey.example.com to provider A, and bar._domainkey.example.com
to provider B.  Provider A could sign messages with a selector such as
aardvark.foo, and B could sign with a selector such as zebra.bar.
> which may not be very natural. (3) has scaling issues transport if
> there were to be
The potential scaling problem with multiple providers in (3) is one of
my main concerns with this approach.  I have heard of enterprises with
upward of 100 authorized mailers, so this has real potential to be an
excessively long list.

I have a somewhat less tangible concern, too.  If example.com publishes
an SSP record saying that some mail provider is an authorized sender,
and there is an abuse problem, will example.com feel the same
responsibility for the use of their address as if the message had been
signed directly "by" their domain?  They may not, and I view any
spreading of the responsibility to be undesirable.

We have put in lots of mechanisms for domains to delegate signing
authority:  they can delegate individual keys, the entire _domainkey
zone, or a subdomain of that.  Mailing providers are free to use the
same keypair to sign for all of their customers, if they want to assume
that risk, and they only need to apply the right domain name and
selector when they sign.  Is that really a big burden?

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 27 Jul 2006 18:50:12 -0400

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, July 27, 2006 2:26 PM
Subject: [ietf-dkim] I sign nothing / only only 3rd party / some mail

> nothing" adds no value. The signature is invalid.

When you have a "Ignore if invalid/error"" BASE methodology, the SSP and
DSAP declaractions is explicit in telling you want to expect.

> "I sign only 3rd party" has the same attack problem as "I sign nothing".

I don't see the attack problem in "I sign nothing" so...

> "I sign some mail" doesn't tell the recipient anything useful.

Agree.  Relaxed polices will be more abused as with anything relaxed. But
lets not confused it with multiple domains where each has a different
policy.  The problem with relaxed policies is when the ratio of abused vs
success gets higher.  So its fine until its starts getting abused and it
might begin to affect all transactions from the domain.  That might be good
or bad.

> What am I missing?

You are telling the world about what you expect with any purported domain
junk coming their way.  The BASE doesn't help them.  SSP does.

---
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 27 Jul 2006 19:01:34 -0400

> "Domain." It sucks to be example.com.
To clarify, by me, I meant my domain.  The problem is that in this type of 
scenario, there is no way to externally distinguish  between mail actually 
sent by the vanity domain owner and mail sent by another customer of 
isp.example.com  

> you, the end user. You're just a user.
As I said, the issue here is the small domain holder sending through a large 
ISP server.

> send something untoward. That has consequences.
Sure, but if you send mail through your ISP's mail server you certainly want 
to make sure their other customers can't do the same with your domain name.

> > associated guidance need to make that clear.
I'm not sure yet.  At this point we're just talking about requirements and if 
this type of requirement is covered through policy or not.

Scott K

---

From: Arvel Hathcock <[email-masked]>
Date: Thu, 27 Jul 2006 18:07:51 -0500

> Besidewhich wont a UI hide the nitty gritty of what bits are set

Hadn't thought of that along those lines.  Yeah, that could work and I'm 
perfectly happy to sign on to this as a solution.

My reservation (which I can get beyond) comes from experiences where 
I've made mistakes as a programmer like this:  I change bit X because 
result Y is no longer required but forgot that bit X was also employed 
in a round-about way to achieve result Z and so now result Z doesn't 
work.  I'm not sure that experience applies here but as a general rule I 
think it's best that whenever discrete units of desirable functionality 
can be defined they should have their own on/off mechanism.

-- 
Arvel

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Jul 2006 16:15:03 -0700

> sent by the vanity domain owner and mail sent by another customer of 
I guess this means that isp.example.com is not worthy of your delegation
of signing authority to them, and you should shop elsewhere (find a more
reliable ISP, or sign your own messages).  I think the ISPs will get it
right fairly quickly if they lose business as a result of not
authenticating mail submission properly (or otherwise fixing whatever
mechanism allowed Joe Spammer's message through).

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jul 2006 16:22:31 -0700

On Jul 27, 2006, at 3:40 PM, Jim Fenton wrote:

>
>> 3) have the ability for the policy statement say that a provider 
>> (s) legitimately signs for that domain.
>
> The potential scaling problem with multiple providers in (3) is one  
> of my main concerns with this approach.  I have heard of  
> enterprises with upward of 100 authorized mailers, so this has real  
> potential to be an excessively long list.

For large enterprises, establishing formalized arrangements where  
either a zone is delegated or a private key and selector information  
is shared with trusted vendors will likely be a typical solution.   
For a vast number of mom and pop outfits, a list of providers  
offering their outbound services would likely never require anything  
more than a few names.  If mom and pop are also active on many  
mailing lists, they may also want to express their list as "open- 
ended" at this time.

> I have a somewhat less tangible concern, too.  If example.com  
> publishes an SSP record saying that some mail provider is an  
> authorized sender, and there is an abuse problem, will example.com  
> feel the same responsibility for the use of their address as if the  
> message had been signed directly "by" their domain?  They may not,  
> and I view any spreading of the responsibility to be undesirable.

Regardless of the OA, spam will reflect poorly upon the signing  
domain.  Reports of abuse and expectations of who will resolve an  
abuse issue  always falls to the signing domain.  There will not be  
any "spreading" of responsibility.  There is no means to know whether  
the OA is even valid!  The identity of the OA depends upon the  
assertion made by the signing domain.

> authority:  they can delegate individual keys, the entire  
> _domainkey zone, or a subdomain of that.  Mailing providers are  
> free to use the same keypair to sign for all of their customers, if  
> they want to assume that risk, and they only need to apply the  
> right domain name and selector when they sign.  Is that really a  
> big burden?

Yes.  For a mom and pop outfit depending upon their ISP for outbound  
mail service, setting up DKIM signing or zone delegations would be a  
big burden.  The support required to handle key or zone arrangements  
would be an increased expense that might impeded DKIM adoption.   
Setting up a static DSD list should be much less effort.  The DSD  
should also represent a significantly lower burden for smaller  
outfits.  They should still obtain improved annotations and be  
affording added protections when their list is closed.  If there is a  
problem, mom and pop would then know where to complain, their  
provider.  They can always find a new provider as well.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Jul 2006 16:23:00 -0700

>> "I sign some mail" flag set?
Might the SSP record that says "I sign some mail", which could have a
long TTL, be more effectively cached by DNS than the (negative) caching
when there's no record?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Jul 2006 16:33:42 -0700

> trivially spoofable unless you have a list of others that are authorized to 
Sure; third-party signatures will have a bigger dependence on
reputation/accreditation/whitelists/etc. than originator signatures.

Using cisco.com as an example, how would we create a list of others that
are authorized to sign?  We have people using mailing lists, "mail this
article to a friend", and similar services all over the place.  There's
no way that we could catalog a complete list.  However, we might want to
white list a bunch of likely-reliable signing domains (e.g., ietf.org,
mipassoc.org and maybe nytimes.com) and treat these messages with less
scrutiny.

-Jim

---

From: Michael Thomas <[email-masked]>
Date: Thu, 27 Jul 2006 16:39:32 -0700

>aardvark.foo, and B could sign with a selector such as zebra.bar.

Hmm, that seems like it could work. Seems pretty complicated though in
real life; I guess I'm just a little skeptical about  mail providers 
managing
other people's DNS in general.

Truth in advertising: I'm very much on the fence about all of this and I'm
only trying to figure out whether there's a big enough constiuency for a
general enough problem that seems like it _could_ be solved such that
it's worthwhile putting into the requirements.

>upward of 100 authorized mailers, so this has real potential to be an
Yep.

>spreading of the responsibility to be undesirable.

That's a good point.

          Mike

---

From: Jon Callas <[email-masked]>
Date: Thu, 27 Jul 2006 16:50:17 -0700

> sent by the vanity domain owner and mail sent by another customer of

I would phrase it as a "situation" or "issue" rather than a "problem."

However, it's not strictly true. Example.com is supposed to be  
signing the "From" header field. (Section 5.4: "The From header field  
MUST be signed....") If the From line from your domain is different  
from the other customers, then it can be distinguished.

> this type of requirement is covered through policy or not.

I think it's covered in the *syntax*.

	Jon

---

From: <[email-masked]>
Date: Thu, 27 Jul 2006 20:07:52 -0400

As an example, an ISP that has 10k business customers who potentially
will want signed mail a
Commercial.isp.com signing domain would assert
I only sign 3rd party
Using current software I would only sign customers that have been
pre-approved. If those customers SPAM for whatever reason, neglect or
deliberate I now have a more accurate method of shutting them off. Abuse
is reported to me as the signer, I then using internal policies fix the
problem. Makes me a somewhat better ISP citizen.
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 Jim Fenton
Sent: Thursday, July 27, 2006 7:34 PM
To: Scott Kitterman
Cc: [email-masked]
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Jul 2006 17:20:01 -0700

> assertion made by the signing domain.

"Spreading" was perhaps not the right word to use.  But the signature is
now coming from a different place, so whom it reflects poorly upon is
now changing.  That makes it a fundamentally different thing than key
delegation.  Allowing a domain to delegate the ability to sign their
mail and not holding the delegating domain responsible at all seems
undesirable in that it doesn't discourage domains from doing business
with dubious mailing services.

-Jim

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 27 Jul 2006 17:45:25 -0700

>long TTL, be more effectively cached by DNS than the (negative) caching

Both should cache equally, shouldn't they? There are not levels of caching.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 27 Jul 2006 21:02:56 -0400

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

> with dubious mailing services.

Is it possible to view this from a VERIFIER security standpoint based on
what is to expected in DKIM-BASE and all possible signatures regardless what
is deemed useful or not?

After, the verifier is going to be the ultimate "controller" of what gets
processed, what get disseminated, filtered, etc.

Regardless of the meaning the possible the DKIM-BASE signature protocol has
left itself unprotected.

As my chart shows in my DSAP proposal (submitted to the IETF), at

http://isdg.net/public/ietf/drafts/draft-santos-dkim-dsap-00.html#anchor14

The verifier is going to see signature(s) or none at all and from its
standpoint each has a possibility of 10 different arrangements:

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.               |
    +-----------------------------------------------------------------+

                  Figure 4: DSAP Message Signing Policies

For the sake of progress, if we set aside 3P policies, we are down to 4
possible OP policies:

 - No Mail Expected by OP (Original Party)
 - No Signing Expected by OP
 - Signing always expected by OP
 - Signaling Optional by OP

It doesn't matter who here thinks if any of these make sense or not. Anyone
can come up with a scenario of when it does or not make sense.  What is more
important is that the VERIFIER will see all the possibilities in the
potential onslaught of DKIM messages.

It would be ideal for the domain to declare what is or not expected in the
mail with purported Domain DKIM markings.

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jul 2006 18:47:39 -0700

On Jul 27, 2006, at 5:20 PM, Jim Fenton wrote:

>> abuse issue  always falls to the signing domain.  There will not  
>> be any "spreading" of responsibility.  There is no means to know  
>> whether the OA is even valid!  The identity of the OA depends upon  
>> the assertion made by the signing domain.
>
> "Spreading" was perhaps not the right word to use.  But the  
> signature is now coming from a different place, so whom it reflects  
> poorly upon is now changing.  That makes it a fundamentally  
> different thing than key delegation.  Allowing a domain to delegate  
> the ability to sign their mail and not holding the delegating  
> domain responsible at all seems undesirable in that it doesn't  
> discourage domains from doing business with dubious mailing services.

There are many organizations that use email-servers to attract users  
and their eyeballs.  Vetting customers is part of their cost of doing  
business.  DKIM makes reporting abuse easier, where then the report  
also has a much greater signal to noise ratio.  DKIM should make this  
domain's life easier, so don't shed any tears or expect anything to  
get worse as a result.

By design, DKIM is not obvious to the recipient without some type of  
annotation.  When just display-names are visible or international  
domain names are used, the recipient may be unable to ferret out  
spoofing attempts based solely upon strict OA policy.  This issue is  
indicated as having both a high impact and high likelihood in the  
Threat draft.  It seems reasonable to assume message annotation  
conveys the signing domain when it does not match the OA.

It seems wrong to suggest a signature is coming from a different  
place.  The signature comes from where the key was obtained.  The OA  
is coming from a different place, but message annotations should make  
this apparent.  While the designation of signing domains by the OA  
could be incorporated into message annotations, this is not really  
required when the signing domain is conveyed.  The signing domain  
should also be annotated when found within a prior correspondence  
list or address book.

As a separate issue from spoofing, message acceptance should improve  
when associations are validated with the DSD list.  It would be  
surprising for Cisco to designate popular mailing list domains,  
however.  It would be likely that Cisco might create a separate  
subdomain in order to establish different policy arrangements.   
Perhaps for staff.cisco.com, the policy would look like:

  staff.cisco.com Policy DSDL: <cisco.com> MODE: Open-ended (allows  
the use of mailing lists)

  cisco.com Policy DSDL: <cisco.com> MODE: Closed-ended (better  
prevents spoofing of transactional messages)

  blue-example.net DSDL: <blue-example.net>, <cisco.com> MODE: Open- 
ended (allows use of companies outbound services and mailing lists)

This may mean that when you want to send messages to a mailing list,  
[email-masked] or [email-masked] would be used,  
instead of [email-masked].  The mode "open-ended" for  
staff.cisco.com and blue-example.com also indicates the OA can be  
signed by any other domain, or even not have a valid signature.   
There does not appear to be a reason to differentiate between being  
signed by some other domain, and not being signed at all.  The  
typical reason for allowing this exception would be to handle  
messages damaged in transit, or messages sent through other outbound  
services such as auction websites and the like.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 27 Jul 2006 20:28:11 -0700

On Jul 27, 2006, at 6:02 PM, Hector Santos wrote:
>
> Is it possible to view this from a VERIFIER security standpoint  
> based on what is to expected in DKIM-BASE and all possible  
> signatures regardless what is deemed useful or not?
>
> After, the verifier is going to be the ultimate "controller" of  
> what gets processed, what get disseminated, filtered, etc.
>
> Regardless of the meaning the possible the DKIM-BASE signature  
> protocol has left itself unprotected.

Your draft retains the Originator Address (OA) of SSP in a limited  
fashion.

The draft uses the term domain without referencing which domain.  It  
is not clear whether domain refers to signing domain or the OA.
For example, the draft makes an odd statement:
,---
| The only case for reliability is when the DKIM
| signature is verified.  However, even then, this
| valid signature may be done on a domain which
| did not authorize this signing process.
'--

I assume this means the OA did not designate the signing domain.   
Rather than considering this a means to authorize or instruct  
receiving verifiers, consider policy related to defining valid  
sources (signing and non-signing) of the OA.

Why indicate the prevalence of a designated signing domain?

Why differentiate between an unknown (not listed) signing domains and  
not being signed or having an invalid signature?

Ensuring DKIM does not cause a spate of delivery problems seems to be  
of greater importance than publishing policy.  It seems making DKIM  
problematic or difficult to manage might kill DKIM adoption.  It also  
seems your table could be greatly simplified.  The list and all of  
these states could be reduced to just a list and a flag that  
indicates whether other sources not included within the list are  
valid.  By allowing other non-listed sources, non-signed sources  
would also be valid.  A closed empty list means there is no valid  
source for this OA.

-Doug

---

From: John Levine <[email-masked]>
Date: 28 Jul 2006 04:16:43 -0000

>will want signed mail a Commercial.isp.com signing domain would
>assert I only sign 3rd party

It may well be true that you only sign third party mail, but I still
don't understand what use a recipient might make of that information.

If they get unwanted mail from someone and you've signed it, they'll
complain to you regardless.

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Thu, 27 Jul 2006 21:23:32 -0700

> Both should cache equally, shouldn't they? There are not levels of
What I meant was that negative caching has a TTL which is the minimum
TTL of the zone (likely to be small), while the SSP record can be given
a long TTL because it's unlikely to change frequently.  However, that's
a pretty marginal benefit.

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Jul 2006 02:19:16 -0400

----- Original Message -----
From: "Douglas Otis" <[email-masked]>
To: "Hector Santos" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, July 27, 2006 11:28 PM
Subject: Re: [ietf-dkim] requirements

> | did not authorize this signing process.

I think I rephrase it. Thanks

In short, it implies DKIM-BASE is based on a "Good Citizen" model where
every "i is dotted" and every "t is crossed."   But it lacks no security
provisions for protecting against the most obvious of all DKIM failures - in
this case as to relates the above statement - unauthorized signings.

DSAP (DKIM Signature Authorization Protocol) is about securing the DKIM-BASE
signing practice of the responsible domain.

---
HLS

---

From: Jon Callas <[email-masked]>
Date: Fri, 28 Jul 2006 00:41:12 -0700

> this case as to relates the above statement - unauthorized signings.

What do you mean by an unauthorized signing, Hector?

Perhaps I don't understand something, but if some unauthorized entity  
owns my DNS and my outgoing MTAs, then I have network problems beyond  
the scope of DKIM.

	Jon

---

From: <[email-masked]>
Date: Fri, 28 Jul 2006 08:48:27 -0400

A recipient will then have a valid party to complain to which is better
than blocking a domain that has been spoofed.
Thanks,

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

-----Original Message-----
From: John Levine [mailto:[email-masked]] 
Sent: Friday, July 28, 2006 12:17 AM
To: [email-masked]
Cc: Oxley, Bill (CCI-Atlanta)
Subject: Re: [ietf-dkim] The URL to my paper describing the DKIM policy
options

R's,
John

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 28 Jul 2006 10:44:36 -0400

----- Original Message -----
From: "Jon Callas" <[email-masked]>

> What do you mean by an unauthorized signing, Hector?

Basically, the responsible domain property owner (Original Address) mail
policy expectations were violated in some form.

Maybe he did not expect any signing or signing by others or vice versa.

> owns my DNS and my outgoing MTAs, then I have network problems beyond

Agree.

The idea being that in order to exploit an OA signature, as you
suggest, the OA network DNS server(s), database, assets, etc, would have to
exploited as well.  This attack (equivalent to a "Theft of Private Key for
Domain" exploit) was deemed as a high impact, but with a low potential
(likelihood) in the TA (Threat Analysis).

However, the higher potential threat is with unauthorized 3rd party
signatures not involving an exploitation of the OA network, including
unauthorized OA spoofs or No Mail expectations.

The easiest example today, in our service, we get about 12% local domain
spoofing - remote systems using our local domain as the originating source.
We trap these.  No other system should expect messages with our domain
coming into their system unless it is directly from us.  This would be what
I would call unauthorized transactions.

---

From: John L <[email-masked]>
Date: Fri, 28 Jul 2006 11:55:25 -0400 (EDT)

> than blocking a domain that has been spoofed.

I still don't understand the scenario.  Let's call the domain isp.com.
Is it:

A) No mail has an isp.com From: address, but mail with other From: 
addresses may have an isp.com signature.

B) Mail goes out with From: addresses at isp.com, but none of it is 
signed.  Mail with other From: addresses may have an isp.com signature.

C) something else.

Scenario A is "we send no mail," with the possibility of third party
signatures on other mail being irrelevant.  Like I said, if you sign it, 
you'll get the complaints no matter what your SSP says.

Scenario B is technically possible but makes no sense.  If you have the
ability to sign mail, why wouldn't you sign your own?

What am I missing here?

R's,
John

---

From: <[email-masked]>
Date: Fri, 28 Jul 2006 12:07:20 -0400

"Scenario B is technically possible but makes no sense.  If you have the
ability to sign mail, why wouldn't you sign your own?"
because this is a special purpose domain simply to manage 3rd party
signage, the domain itself will not send any mail. Saying I only sign
3rd party would allow people to regard any purported mail from that
domain with a large degree of suspicion
thanks,

What am I missing here?Bill Oxley 
Messaging Engineer 
Cox Communications, Inc. 
Alpharetta GA 
404-847-6397 
[email-masked] 

-----Original Message-----
From: John L [mailto:[email-masked]] 
Sent: Friday, July 28, 2006 11:55 AM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]
Subject: Re: 3rd party signing

C) something else.

What am I missing here?

R's,
John

---

From: Michael Thomas <[email-masked]>
Date: Fri, 28 Jul 2006 09:17:02 -0700

> addresses may have an isp.com signature.

Consider what I believe Y! does in their MUA: if it's got a valid 
signature from isp.com
with a From: [email-masked], it doesn't get a nice little message 
saying that Y!
believe it came from customer.com. Thus the outsourced mail will not be 
treated on
a par with mail signed on behalf of the domain.

That's something.

       Mike

> signatures on other mail being irrelevant.  Like I said, if you sign 
> it, you'll get the complaints no matter what your SSP says.
>

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Jul 2006 09:56:55 -0700

On Jul 28, 2006, at 9:17 AM, Michael Thomas wrote:

> John L wrote:
>
>>>> It may well be true that you only sign third party mail, but I  
>>>> still don't understand what use a recipient might make of that  
>>>> information.

John,

This is about policy related to the OA and not the signer.  The OA  
could indicate that they never sign for themselves.  This information  
would allow rejection of bogus and invalid signatures.  Perhaps this  
domain signs for others, but that is not germane to OA policy.)

> signature from isp.com with a From: [email-masked], it doesn't  
> get a nice little message saying that Y! believe it came from  
> customer.com. Thus the outsourced mail will not be treated on a par  
> with mail signed on behalf of the domain.

Mike,

Agreed.  One gets what they pay for so to speak.  Being able to  
associate a foreign From with the signing domain should improve  
acceptance and provide a commensurate reduction in related support  
calls however.

-Doug

---

From: John L <[email-masked]>
Date: Fri, 28 Jul 2006 13:55:54 -0400 (EDT)

> signage, the domain itself will not send any mail.

Right, that's scenario A.

> Saying I only sign 3rd party would allow people to regard any purported 
> mail from that domain with a large degree of suspicion

Right.  How is this usefully different from "I send no mail"?

R's,
John

---

From: John L <[email-masked]>
Date: Fri, 28 Jul 2006 14:06:18 -0400 (EDT)

> signature from isp.com with a From: [email-masked], it doesn't get a 
> nice little message saying that Y! believe it came from customer.com. 
> Thus the outsourced mail will not be treated on a par with mail signed 
> on behalf of the domain.

It makes sense that customer.com would publish an SSP record saying "my 
mail is all signed by isp.com".

But I still don't see what benefit it is for isp.com to say "we sign some 
other people's mail."  If isp.com signs other people's mail, we'll know 
because we'll see the signatures.

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

---

From: Jim Fenton <[email-masked]>
Date: Fri, 28 Jul 2006 11:17:53 -0700

> So you always need to check for SSP first.
So you mean "with a valid signature existing?"  If so, isn't that a
contradiction in the published information, so why should I assume SSP
is right?

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Fri, 28 Jul 2006 11:38:37 -0700

Michael Thomas wrote:
> believe it came from customer.com. Thus the outsourced mail will not
> be treated on
But suppose example.com is not a customer of isp.com but yet a message
from example.com has a valid signature from isp.com.  Are you saying
that Y! should say that it believes it came from example.com, based on
the assertion by isp.com that it only signs third-party messages?

Maybe I have trimmed off too much context here, I thought we were
discussing the value of an "I only sign third-party messages".  I'm with
John; I don't see how that provides any useful information to the verifier.

-Jim

---

From: John L <[email-masked]>
Date: Fri, 28 Jul 2006 14:52:51 -0400 (EDT)

> the assertion by isp.com that it only signs third-party messages?

We certainly seem to have a lot of ambiguity if not confusion about 
terminology.

If a receiver is going to be looking up SSP data, is it going to look up 
the domain in a message's signature?  In the From: line?  In some PRA-ish 
function of various headers?  All of the above?  Some of the above in a 
fixed order?  Some of the above in an implementation-dependent order?

Can an additional signature ever decrease a message's reputation?  I would 
argue no.

If a message has a valid signature from the same domain as the From: 
domain, can SSP tell you anything useful?  If you looked up the SSP on 
such a message and it said "we send no mail", who do you believe?  (Keep 
in mind that if the signature is valid, the same DNS that had the SSP also 
had the DKIM key.)

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Fri, 28 Jul 2006 11:54:16 -0700

On Jul 28, 2006, at 11:38 AM, Jim Fenton wrote:

>>> A) No mail has an isp.com From: address, but mail with other  
>>> From: addresses may have an isp.com signature.
>>
>>
>> customer.com. Thus the outsourced mail will not be treated on a  
>> par with mail signed on behalf of the domain.
>
> But suppose example.com is not a customer of isp.com but yet a  
> message from example.com has a valid signature from isp.com.  Are  
> you saying that Y! should say that it believes it came from  
> example.com, based on the assertion by isp.com that it only signs  
> third-party messages?

A better ISP could confirm the valid use of an email-address as a low  
cost means of enhancing their services.  This might involve noting  
that the email-address has not been used previously be this user and  
request that they confirm that they receive messages for this address  
by clicking on a link, for example.  With such an ISP, it would be  
safe to list them as a designated signer and still avoid spoofing.

> discussing the value of an "I only sign third-party messages".  I'm  
> with John; I don't see how that provides any useful information to  
> the verifier.

I think that Bill poorly stated the desired policy.  It should have  
been from the perspective of the OA rather than the signer.  This  
should have been that there are no designated signers for the OA of  
this domain.  Whether this domains signs messages for other OAs would  
be independent of this assertion.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Jul 2006 08:49:19 -0700

> long TTL, be more effectively cached by DNS than the (negative) caching

how does a "i sign some mail" help?

If a message is signed, it either validates or it doesn't.

If a message is not signed, then how does a "some mail" ssp flag help?

d/
-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Sun, 30 Jul 2006 08:55:30 -0700

John L wrote:
> I still don't understand the scenario.  

It occurs to me that discussion of usage scenarios should be required for every
requirement.

It is easy to state a functional "requirement" but it is often difficult to
explain why it is needed or to convince people that it is essential to support
that requirement.

The easiest way to handle this is to ensure that every functional requirement is
explained in terms of a detailed usage scenario, so that the feasibility and
urgency of that usage can be considered by the working group.

d/

-- 

  Dave Crocker

---

From: Mark Delany <[email-masked]>
Date: Sun, 30 Jul 2006 16:27:47 +0000

> urgency of that usage can be considered by the working group.

Quite. Given the range and scope of the alternatives being discussed,
this sure feels like a green-field design environment.

I worry that we may not even have a very good handle on what is
actually wanted in the field, consequently we risk designing something
that targets engineers as the customer.

Mark.

---

From: "Hector Santos" <[email-masked]>
Date: Sun, 30 Jul 2006 15:15:57 -0400

----- Original Message -----
From: "Mark Delany" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, July 30, 2006 12:27 PM
Subject: Re: [ietf-dkim] scenarios

> this sure feels like a green-field design environment.

The range and scope are bounded by DKIM-BASE.   DKIM-BASE is whats out
there.  Now you got to control the possible unprotected behavior of it.

> that targets engineers as the customer.

Well you need engineers to work it out.   Who is the customer any way?
Well, that depends on the hat one wishes to wear.  t may be the domain,  it
may be the verifier, it may also include the end user.  It may also include
the infrastructure for the network guy concern about network abuse. It is
also the administrator and so on.   From my standpoint,   all parties are
the customer and  to increase the acceptability of the DKIM protocol, it
needs to offer value to all parties.

My critical concern is the extremely high potential for abuse at the
receiver.   For the legacy market or for the market who does not choose or
slow to support DKIM, what the receiver does not know about DKIM, no harm is
done to them.   However, those who begin to support DKIM verification,  can
easily see the potential abuse of DKIM-BASE is very high.

If the abuse ratio is high, you might find the system will declare it not
worth the processing overhead (as we did with DomainKeys, the failures on
the incoming DK signed mail was overwhelmingly too high).

But I happen to believe we can control the fundamental parts of DKIM-BASE
using signature authorization controls.  Watering them down is not giving to
help it.

I think not understanding something does not give those who do, those who
has put in the time to help engineer this all out, from a real production
standpoint, the benefit of the doubt.

The SSP interface is actually quite simple to implement.  If we go back to
the old mailing list, most of the concern was about redundant DNS lookups,
atleast that was Jim's stated concern.

Let me know if these interface diagram helps:

      http://www.winserver.com/public/ssp/ssp.htm

---

From: Mark Delany <[email-masked]>
Date: Sun, 30 Jul 2006 19:41:13 +0000

> standpoint, the benefit of the doubt.

Thanks, you demonstrate the point nicely.

Mark.

---

From: Michael Thomas <[email-masked]>
Date: Sun, 30 Jul 2006 15:55:16 -0700

>contradiction in the published information, so why should I assume SSP
Especially when you consider that would be a big fat juicy target
for a would-be DOS attacker: spoof SSP "i don't send email" policy
and now all of the sudden legitimately signed mail looks extremely
suspicious.

       Mike

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 31 Jul 2006 06:15:55 -0700 (PDT)

On Fri, 28 Jul 2006, John L wrote:

>> Consider what I believe Y! does in their MUA: if it's got a valid signature 
>> from isp.com with a From: [email-masked], it doesn't get a nice little 
>> message saying that Y! believe it came from customer.com. Thus the 
>> outsourced mail will not be treated on a par with mail signed on behalf of 
>> the domain.
>
> It makes sense that customer.com would publish an SSP record saying "my mail 
> is all signed by isp.com".
>

The statement that I sign only my own mail makes perfect sense.

---

From: John L <[email-masked]>
Date: Mon, 31 Jul 2006 09:42:51 -0400 (EDT)

> The statement that I sign only my own mail makes perfect sense.

If I have a message with your valid 3rd party signature, meaning that 
you've published the key, and your SSP says you sign only your own mail, 
which do I believe?  Why or why not?

Regards,

---

From: John L <[email-masked]>
Date: Mon, 31 Jul 2006 09:57:08 -0400 (EDT)

> You [optionally] report this error to me and classify this as likely bad 
> email due to policy.

Why should I believe the SSP rather than the signature?  You signed it, 
you're responsible for it.  If experience with SPF is any guide, most 
non-trivial SSP records will be wrong because the people setting them up 
won't understand what they mean.

On the other hand, if your software is so buggy that it signs mail with 
random other From: lines when it's not supposed to, why are you signing at 
all?

Regards,

---

From: <[email-masked]>
Date: Mon, 31 Jul 2006 09:59:19 -0400

You believe both and apply a receiver policy determined by yourself that
will handle a message with an anomaly,

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 L
Sent: Monday, July 31, 2006 9:43 AM
To: william(at)elan.net
Cc: DKIM List
Subject: Re: [ietf-dkim] Re: 3rd party signing

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for
Dummies",

---

From: John L <[email-masked]>
Date: Mon, 31 Jul 2006 10:02:07 -0400 (EDT)

I have to say that the more discussion I see from advocates of SSP, the 
less I think that anyone really understands what it's supposed to do.

So here's the main SSP axiom that I think should be self-evident, but 
apparently isn't: other than the trivial (but useful) case of I send no 
mail, the most that SSP can tell you is that a signature is missing.

If a message has a signature, no amount of SSP can unsign it.  It might be 
able to say that a signature is missing, e.g., it's signed by your ISP but 
the SSP says it's supposed to be signed by you, too.

The other axiom is that any useful SSP statement (again excepting I send 
no mail) contains "all".  Statements like "I sign some mail" are useless, 
because they validate any message, signed or not.  Statements like "I sign 
no mail" are useless because recipients will already have figured that out 
when they see no signatures, or else your SSP is broken if they do see 
signatures.

Regards,

---

From: John L <[email-masked]>
Date: Mon, 31 Jul 2006 10:03:06 -0400 (EDT)

> will handle a message with an anomaly,

What is the benefit of allowing people to publish SSP statements that are 
either self-evident or wrong?

Regards,

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jul 2006 07:58:59 -0700

> The statement that I sign only my own mail makes perfect sense.

There are a few problems with this statement. The policy reference will
be from the OA domain and not the signing domain.  In what context would
this policy even be in the right context?  If there is a valid
signature, that would trump non-signed policy information counter to
that valid signature.  If there are attempts to use a bogus signature,
the protection being sought is for the OA domain and not the signing
domain. Are you suggesting that there be additional transactions made
for known bogus signatures?

A domain found based upon reverse DNS of the SMTP client or EHLO
validation might have be when such a check may have been made.  Upon
validation, the next check would likely be of their reputation and not
what else they have to say.  This seems to suggest that a bogus
signature could be held against this domain unless they disavow even the
possibility?  Would you want this policy to list thousands of domains,
which might be the typical case?  This type of policy would seem to
create a management headache for little benefit.

-Doug

---

From: Mark Delany <[email-masked]>
Date: Mon, 31 Jul 2006 15:09:44 +0000

> will handle a message with an anomaly,

I'm with John on this. I don't see any merit in constructing a system
that allows anomalies soley for the purpose of giving a receiver less
certainty and more work to do.

Mark.

---

From: Arvel Hathcock <[email-masked]>
Date: Mon, 31 Jul 2006 11:28:03 -0500

> such a message and it said "we send no mail", who do you believe?
 > (Keep in mind that if the signature is valid, the same DNS that had
 > the SSP also had the DKIM key.)

Yes, yes.  John is right.  "We send no mail" does have an inherent 
contradiction problem.  Dumping it would rid us of that problem and 
allow an optimization because we wouldn't have to do SSP queries in 
cases where there's a valid signature on behalf of the From: domain.

-- 
Arvel

---

From: wayne <[email-masked]>
Date: Mon, 31 Jul 2006 11:43:56 -0500

+1

This is much like the reason I don't like stuff in the rDNS that
indicates that "this machine should never send email".  If you want
that policy, do port 25 blocking.  Don't make the rest of the world
try to figure out whether you screwed up on your security or you
screwed up on you published policy.  And, have to do that all after
receiving the traffic.

-wayne

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jul 2006 08:12:19 -0700

On Mon, 2006-07-31 at 10:02 -0400, John L wrote:

> If a message has a signature, no amount of SSP can unsign it.  It
> might be able to say that a signature is missing, e.g., it's signed by
> your ISP but the SSP says it's supposed to be signed by you, too.

Agreed.

> The other axiom is that any useful SSP statement (again excepting I
> send no mail) contains "all".  Statements like "I sign some mail" are
> useless, because they validate any message, signed or not.

This depends.  If there is a list of designated signing domains, and an
exception that allows other non-designated domains, then the benefits
might be limited to just the designated domains, where this would be
useful in assuring delivery.

> Statements like "I sign no mail" are useless because recipients will
> already have figured that out when they see no signatures, or else
> your SSP is broken if they do see signatures.

The marginal benefit would be found when dealing with the handling of
invalid signatures.  Are they bogus or broken?  A policy statement could
short-cut several transactions attempting to deal with these cases.
While there should be no key, the lack of a key could also occur for
other reasons.  Being direct seems to have some value.  

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 31 Jul 2006 12:58:24 -0400

----- Original Message -----
From: "Arvel Hathcock" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 31, 2006 12:28 PM
Subject: Re: [ietf-dkim] Re: 3rd party signing

> cases where there's a valid signature on behalf of the From: domain.

-1.  John is not right. He says he is an SSP fog and indicates he doesn't
understand, so how could he be right?

Anyway,  a NO MAIL policy is clearly that.  We send mo mail.  There is
nothing to believe but what's expose in the Domains DNS storage.  The only
harm is to the domain, and if we can't trust the DNS storage, then we got
more inherent problems with DKIM.

Think about it, if we can't trust SSP than why should we trust the DKIM
signature?  The optimization comes by lowering your DKIM processing overhead
by avoiding such irregulaties that CLEARLY are very strong domain protection
policies.

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 31 Jul 2006 13:13:19 -0400

----- Original Message -----
From: "wayne" <[email-masked]>
To: <[email-masked]>
Sent: Monday, July 31, 2006 12:43 PM
Subject: Re: [ietf-dkim] Re: 3rd party signing

> In <[email-masked]> Mark Delany
<MarkD+dkim@yahoo-

> screwed up on you published policy.  And, have to do that all after

-1.

In my view, this is exact philosophy the "bad guy" will be hoping will
become of all this.

If you allow mediocrity to exist, you will get medico as the basis for
abuse.  This has been the modus operandi and hallmark of the SMTP mail abuse
problem. That is why we are even bothering with all this.

SSP, if any one has bother to read the specs, or even my specs, offers a
streamlined "no figuring out" deterministic concept of simply authorizing a
purported signature or lack thereof or unauthorized 3rd party signature,
etc.

We were seeing quite of few invalids Domainkeys with fake domains that doe
not exist.  Are we expecting DKIM to be exception to this obvious abuse
rule?

Keep in mind, with DKIM-BASE, we have a methodology that says "Ignore
Invalids."  How does anyone expect this unprotected methodology to not be
exploited.

With DKIM-SSP, it helps eliminate the high potential abuse of "Ignore
Invalids."

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 31 Jul 2006 06:52:18 -0700 (PDT)

On Mon, 31 Jul 2006, John L wrote:

> If I have a message with your valid 3rd party signature, meaning that you've 
> published the key, and your SSP says you sign only your own mail, which do I 
> believe?  Why or why not?

You [optionally] report this error to me and classify this as likely bad 
email due to policy. The reason for having it is to avoid cases of one of 
my users improperly "relaying" through my system when they should not
have access to it or should not be using it that way (operationally this
should be stopped on my end but I can assure you that its not going to
always be so either by misconfiguration or due to unknown exploits).

---

From: Douglas Otis <[email-masked]>
Date: Mon, 31 Jul 2006 11:42:17 -0700

On Jul 31, 2006, at 10:13 AM, Hector Santos wrote:

>
> We were seeing quite of few invalids Domainkeys with fake domains  
> that do not exist.  Are we expecting DKIM to be exception to this  
> obvious abuse rule?

DKIM will not reduce the level of abuse.  Bad actors are equally  
capable of signing, mimicking non-DKIM use scenarios, and acquiring  
new and used domain names.  DKIM coupled with additional methods to  
associate message elements with that of the signing domain should  
improve delivery.  An association with the signing domain with other  
message elements may also assist during the envelope phase.

> Keep in mind, with DKIM-BASE, we have a methodology that says  
> "Ignore Invalids."  How does anyone expect this unprotected  
> methodology to not be exploited.

Don't expect DKIM to be widely adopted when this means that mailing- 
lists and the like leads to delivery failures.  Permit a reasonable  
policy statement that enables simpler modes for utilizing DKIM.  DKIM  
without policy still provides tremendous benefit.

> With DKIM-SSP, it helps eliminate the high potential abuse of  
> "Ignore Invalids."

Please don't think of OA policy as an obstacle that email must  
avoid.  Bad actors are most able at navigating around impediments.   
Think of policy as a means for small outfits to obtain an alternative  
method for the signing domain to be associated with the OA domain.   
In general, obstacles will block valid messages, but eventually few  
abusive messages.  Aggressive blocking based upon policy will raise  
support costs and cause user dissatisfaction will little impact upon  
the overall level of abuse.  Alternatively, an association between  
the OA and signing domain might improve delivery (avoid delays or  
placement in the junk folder).

In exceptional cases where transactional messages are being spoofed,  
there is also the issue of just the display-name being visible, look- 
alike, and international domain names where spoofing might continue  
despite strict DKIM policy.  Blocking this form of abuse requires  
comparing content within the message against known good sources of  
such content based upon appearance.  This type of effort seems beyond  
DKIM policy, although DKIM sans policy assists in reducing the false  
positive rate of this process.

-Doug

---

From: "william(at)elan.net" <[email-masked]>
Date: Mon, 31 Jul 2006 12:19:43 -0700 (PDT)

>> certainty and more work to do.

print "-1\n" while +1;

> screwed up on you published policy. And, have to do that all after

My ISP operational & experience is that just filtering on outgoing side
is not enough and eventhough you try to do the right thing the eventually 
your system will get compromised in some way and there needs to be a 
backup plan that takes over. So there is nothing wrong with policy
record that says I don't sign emails at all or I don't sign somebody
elses email. And if receivers believe this policy is not useful and
not necessary of course they will just not check for it or ignore it.

[OT to this WG list follows]

For port25 blocking outside is also true that many ISPs are just not
willing to filtering on their outgoing network end (for various
reasons some having to do with legal agreements) but may well be
willing to mark their network as part of adding PTR records. This is
also OT to this group but after some time I came to conclusion that
if we have PTR email policy records, we should not allow easy way
to add them to entire ip block and should instead force to add record
for each ip address in the same way they'd do it when adding PTR.
This is to make sure ISPs actually are maintaining it all properly.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2006 12:29:12 -0700

> will handle a message with an anomaly,

Please fortive me for characterizing it this way, but this seems to be an
exemplar of the "do whatever feels good" school of protocol design.

There is a pretty substantial history that says that Internet protocols succeed
when they are simple and precise and that their core semantics carry little or
no opportunity for making semantic choices.

d/

-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 31 Jul 2006 12:29:30 -0700

+1

d/
-- 

  Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 31 Jul 2006 16:09:32 -0400

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

> There is a pretty substantial history that says that Internet
> protocols succeed when they are simple and precise and that
> their core semantics carry little or no opportunity for
> making semantic choices.

I agree, and in my view, SSP and DSAP is consistent with this old school
mentality but with a renewed focus not to play down the obvious for the sake
of unrestricted usefulness which in the old days, the problems were
rightfully negligible.

That doesn't apply today with an high alertness of security and abusive
nature of email broadcasting.

SSP/DSAP addresses the unprotected semantics of the DKIM-BASE protocol.

The problem seems to be that these DKIM-BASE defined semantics do not need
protection.

Overall, the DKIM-BASE protocol consistency questions will be:

  o  Does the domain ever distribute mail?
  o  Do you expect the mail to be unsigned?
  o  Do you expect to sign all mail?
  o  Is your domain the exclusive signer?
  o  Are 3rd party signers or signatures allowed?
  o  Are 3rd party signers allowed to strip your original signatures?

These are basic fundamental signature authorization considerations that are
lacking in the core DKIM protocol message signature  methodology.