Subject: [ietf-dkim] Delegating responsibility: a make vs. buy design decision

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Aug 2006 13:50:16 -0700

Folks,

The SSP thread on delegation is doing an excellent job of exploring the problems
with inventing a new delegation mechanism.  What it is *not* doing is exploring
the benefits of using an existing one, instead.

The discussion is based on having SSP invent a means of declaring delegated
responsibility, so that some other operator's domain can create the signature,
but still permit using the author's domain for making assessments.  Given that
email can go through re-postings, while retaining the same author field
(rfc2822.From) this creates a serious problem in determing whether the
"delegated" signature is legitimate, as Jim has noted.

One of the problems with having higher-level discussions that use terminology
that is based on underlying mechanism, is that it obscures its (higher-level)
intended use.  So, "first-party" and "third-party" certainly have meaning, in
terms of indicating some indirection in the relationship among signatures, but
they do not really tell us what the issue is.  The perspective is so mechanical,
it actually can confuse the "policy" discussion, I believe.

I am assuming that the real issue is whose domain name is supposed to be used
for evaluations:

     Should the recipient use the author's domain or should they use (one of)
the operators' domains?

     (Operator typically means someone who handled the message, but might mean a
signature by an independent assessment service.)

I assume that the term "first-party" means that the signature is provided by an
entity operating within the Administrative Domain (ADMD) of the author, and that
third-party means that the signature is provided by an entity that in an ADMD
that is independent of the author.

So, all of this concern about "delegation" is for ensuring that an operator ADMD
signature is known to be authorized by the author's ADMD.

To deal with this, we first have SSP invent a declaration of delegation and,
since this introduces the hole that Jim has described, we are now discussing
invention of an additional mechanism to fix the problem created by the first
invention.  Methinks we should worry about additional mechanisms designed to fix
new mechanisms, as well as the likelihood that we will find ourselves needing
even more such fixes.

An alternative is to have *no* SSP mechanism for delegation.

DNS already provides a means of delegating.

Let's use it, as has already been discussed:

     If author.com wants to make isp.com be authorized to sign on behalf of
author.com, then all that is needed is a DKIM entry for isp.com to use, under
author.com.

For example, imagine a signature made with the domain isp.author.com.  The
author.com folks merely have to create a DKIM record under isp.author.com, and
give isp.com the associated private key.  isp.com uses d=isp.author.com.

The site evaluating the signature sees that the signature and the rfc2822.from
field have "related" domains.  Hence the signature is "authorized" and the
author.com domain is used for making further assessments.

At the very worst, the administrative effort this places on author.com is
exactly the same as we are contemplating for the new SSP mechanism.  And it
eliminates the need for an SSP query about "delegation".

This mechanism already exists, is notably simpler than the one being discussed,
and does not suffer the security hole that has been noted.

Simply stated:

     If the author's domain is to be used for assessment activities, then have
the signature be made with a domain that is directly related to the author.

     If an operator's domain is to be used for assessment activities, then have
the signature be made with a domain that is directly related to the operator.

To explore this approach a bit further, I'm going to wonder about the supposed
need for an SSP check when a signature is present.

     If a signature uses a domain related to the author's domain, then we have
no SSP issue.  The author's domain is used for assessment.  No SSP query need be
made.

     If a signature is not present, THEN an SSP "I sign everything" record might
be useful (modulo the problem of surviving mailing list.)

     If a signature is present, but is not associated with the author's domain,
then make the assessment based on the signing domain, not the author's domain.
Again, no SSP query is needed.

OK.  Start shooting...

d/

-- 

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

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

---

From: [email-masked] (Wietse Venema)
Date: Thu, 17 Aug 2006 18:11:18 -0400 (EDT)

> no SSP issue.  The author's domain is used for assessment.  No SSP query need be

[Plus a straightforward DNS-based delegation mechanism so that the
author's ISP can use a UNIQUE signing domain that relates directly
to the author's domain]

> Again, no SSP query is needed.

I like this. This is very close to what I want: signed mail that
speaks for itself, whether it's first-party or third-party signed.
No batteries required.

	Wietse

---

From: Damon <[email-masked]>
Date: Thu, 17 Aug 2006 18:31:48 -0400

> speaks for itself, whether it's first-party or third-party signed.

Sounds good to me. But it's late... :-)
+1 anyway

Damon

---

From: Douglas Otis <[email-masked]>
Date: Thu, 17 Aug 2006 16:05:56 -0700

On Aug 17, 2006, at 1:50 PM, Dave Crocker wrote:

>
> I am assuming that the real issue is whose domain name is supposed  
> to be used for evaluations:
>
>      Should the recipient use the author's domain or should they  
> use (one of) the operators' domains?

The policy is referenced from the 2822.From domain (author's  
domain).  This policy should be able to designate which domains are  
authoritative for the 2822.From domain.  This list may include the  
2822.From domain, but it might not.  This list may also include other  
domains.

> I assume that the term "first-party" means that the signature is  
> provided by an entity operating within the Administrative Domain  
> (ADMD) of the author, and that third-party means that the signature  
> is provided by an entity that in an ADMD that is independent of the  
> author.

The need for a "first-party" signature process decision ends once  
policy is being obtained.  Any signature is then determined to be a  
"designated domain" or a "non-designated domain" which indicates  
whether the domain is authoritative for the 2822.From address.  This  
determination could occur with a "first-party" signature, where this  
may have value at blocking non-validated parent domain signatures,  
for example.

> So, all of this concern about "delegation" is for ensuring that an  
> operator ADMD signature is known to be authorized by the author's  
> ADMD.

Delegation can refer to a key/selector exchange or a key zone  
delegation in DNS.  A "designated domain" would be a domain listed in  
the 2822.From policy.

> To deal with this, we first have SSP invent a declaration of  
> delegation and, since this introduces the hole that Jim has  
> described, we are now discussing invention of an additional  
> mechanism to fix the problem created by the first invention.

There is no hole, and there is no invention.  The problem that Jim  
described is based upon using a "validating" signature applied to a  
non-validated 2822.From address.  It would not matter whether a  
policy based designated domain list was being used or not.  There is  
no additional mechanism that can fix a bad practice.  This bad  
practice means this signing domain can not be trusted with respect to  
the validity of the 2822.From addresses.  Of course, such a domain  
should not be a designated domain, and should not be certified as  
being suitable for designation.

> Methinks we should worry about additional mechanisms designed to  
> fix new mechanisms, as well as the likelihood that we will find  
> ourselves needing even more such fixes.

The problem does not exist with a domain designation offered by the  
2822.From policy.  There is no additional fix needed as a result.  If  
the 2822.From domain is not validated and properly constrained,  
adding a signature only indicates from which domain the message  
originated.  It says nothing about whether the 2822.From is valid.   
Here policy can have an empty list of authoritative domains for this  
2822.From which states the 2822.From _is_ uncertain.  This situation  
is communicated by having a designated domain list that should  
include _all_ authoritative domains including the "first party" domain.

On the other hand, if the signing domain actually does validate the  
proper use of the 2822.From domain, it does not matter what the email- 
address might be.  If this address domain finds they can trust the  
signing domain, they are also able to designate them as an  
authoritative domain.  Here again, that state is accurately conveyed  
by having a list of designated domains in the 2822.From policy.

> DNS already provides a means of delegating.

This will require that three parties coordinate to establish this  
relationship.  This also requires a fair amount of interaction  
between these three parties.  Using policy to designate a domain  
allows autonomous management of designated domains between a customer  
and a domain name service provider using an existing relationship.

>   If author.com wants to make isp.com be authorized to sign on  
> behalf of author.com, then all that is needed is a DKIM entry for  
> isp.com to use, under author.com.

This would require registering with the email-provider the address  
that must be treated differently.  It would require establishing the  
selector used in their domain, and exchange a private key.  The other  
alternative is to have the zone delegated to the ISP, perhaps along  
other leafs to several other ISPs.  The exact location of this  
delegation needs to be communicated.  While not overwhelming, this  
represents a fairly complex process compared to a DNS provider  
offering a "fill in the blank" entry form that much match a FQDN.   
This entry form can exclude the many details related to the one or  
more email-providers implementation of DKIM.

> For example, imagine a signature made with the domain  
> isp.author.com.  The author.com folks merely have to create a DKIM  
> record under isp.author.com, and give isp.com the associated  
> private key.  isp.com uses d=isp.author.com.

Not exactly.  This will not validate the 2822.From domain for an  
email-address at [email-masked].  The key could be at  
isp._domainkey.author.com and they could then sign d=author.com.   
This would require telling isp.com where the key lives when giving  
them the key.  Isp.com would then need to recognize that any message  
coming from author.com should be signed with this key.  That involves  
a fair amount of interaction between the three parties, the name  
service provider, the email-provider, and the domain owner.  Being  
able to designate a domain means that only the domain name provider  
is involved in a much simpler transaction.

> The site evaluating the signature sees that the signature and the  
> rfc2822.from field have "related" domains.  Hence the signature is  
> "authorized" and the author.com domain is used for making further  
> assessments.

Except for the minor detail, yes.  This does require special  
arrangements per customer.  One alternative that would be easier to  
automate would be to ensure receipt of the 2822.From address used by  
each account separately.  This would protect individuals with email- 
addresses within the ISPs domain, while also safely allowing their  
custom's the use of their desired 2822.From address.  This process  
could function in a manner similar to that of a mailing-list  
subscription.  This should prevent enough support calls to make this  
approach the preferred low cost solution.

> At the very worst, the administrative effort this places on  
> author.com is exactly the same as we are contemplating for the new  
> SSP mechanism.  And it eliminates the need for an SSP query about  
> "delegation".

That is not right.  Listing a designated domain may also mean no  
other DKIM key information needs to be published.  The domain owner  
does not need to know how to generate the key and how to add the  
other key half to their DKIM signing MTA.  If the domain owner  
decides to sub-contract this service, then the domain owner must  
coordinate with two service providers details that vary depending  
upon how the email provider wants to handle a delegation process.  A  
designated domain list is by far simpler, involves only the  
interaction with one service provider, and where the details are  
limited to being just a FQDN.

> This mechanism already exists, is notably simpler than the one  
> being discussed, and does not suffer the security hole that has  
> been noted.

The delegation approach will be fine for some domains.  For many  
smaller outfits, DNS delegation is not a practical solution.

> Simply stated:
>
>      If the author's domain is to be used for assessment  
> activities, then have the signature be made with a domain that is  
> directly related to the author.

The whole purpose for 2822.From policy is to better validate this  
address.  A designated domain list that includes the author's domain  
clearly communicates that this domain validates the 2822.From address  
as belonging to the author.  This could be done by verifying receipt  
prior to permitting its use.  When this mode of verification is used,  
it does not matter what 2822.From is used.

>      If an operator's domain is to be used for assessment  
> activities, then have the signature be made with a domain that is  
> directly related to the operator.

How is this any different?  If a 2822.From domain is signed by a  
designated domain, why is that not a greater assurance than a message  
where the 2822.From domain is the same domain as that of the signing  
domain?  If the signing domain is well-known and trusted for  
validating the 2822.From, then using the well-known signing domain  
would offer greater advantages with respect to assessments.

> To explore this approach a bit further, I'm going to wonder about  
> the supposed need for an SSP check when a signature is present.
>
>      If a signature uses a domain related to the author's domain,  
> then we have no SSP issue.  The author's domain is used for  
> assessment.  No SSP query need be made.

What is being asserted when an email-address is within the same  
domain as the signing domain?  Is this domain claiming to be  
authoritative for the 2822.From domain?  Is the signing domain a  
parent domain of the 2822.From domain?  Perhaps policy indicates that  
there are no authoritative domains, should the identity of the  
2822.From address be considered trustworthy?

>      If a signature is not present, THEN an SSP "I sign everything"  
> record might be useful (modulo the problem of surviving mailing list.)

This also works with a designated domain list.  A flag can indicate  
"only" (the list represents the exclusive source for the 2822.From).   
In which case, when the list is empty, there should no mail from this  
domain.  When there is a domain listed, only those domains should  
carry the 2822.From.

>      If a signature is present, but is not associated with the  
> author's domain, then make the assessment based on the signing  
> domain, not the author's domain. Again, no SSP query is needed.

It would also be good to know whether the domain stipulates whether  
or not they use common services where this might cause non-complaint  
messages.  A phished domain might be very willing to make this  
stipulation.  Many other domains may wish to indicate otherwise.  The  
use of "All" and "Only" flags permits differentiating between  
scenario 1 and 2 of the requirements draft.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Aug 2006 16:11:07 -0700

offlist

> author's ISP can use a UNIQUE signing domain that relates directly

hence the examble's using isp.author.com, yes?

> speaks for itself, whether it's first-party or third-party signed.

and just to make sure *I* understand what you mean:  mail signed by the author,
or mail signed by an operator?

d/

-- 

  Dave Crocker

---

From: [email-masked] (Wietse Venema)
Date: Thu, 17 Aug 2006 19:33:04 -0400 (EDT)

> offlist

This was on-list, thus my reply on-list...

> or mail signed by an operator?

Whether the signing domain is the author's domain (1) or whether
the signing domain is an unrelated domain (2)

(1) Secret key with the author, or delegated to author's ISP.
(2) A mailing list operator, an operator that stamps mail as
"no known virus present", or some other transit service.

	Wietse

---

From: Dave Crocker <[email-masked]>
Date: Thu, 17 Aug 2006 16:50:17 -0700

> This was on-list, thus my reply on-list...

sorry 'bout that.  not a big deal, tho.

> "no known virus present", or some other transit service.

right.

   (1) uses a domain directly associated with the author domain.

   (2) uses some other domain (that is associated with the operator doing the
signing.)

d/
-- 

  Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 17 Aug 2006 20:20:04 -0400

Dave, this is not off-list, but I would say its off-base. :-)

All you guys are showing is how Relaxed Policies can be abused.  No more, no
less.  Most everyone understood this and thus why SSP strong policies are
necessary to be part of the total package.

You guys are stuck on allowing *anyone*, any middle ware software signing
mail along the transaction path to be OK!

If the DOMAIN is going to allow his ISP to sign mail on his behalf, meaning
the ISP has full control of the DOMAINS private key, then the DOMAIN should
have a policy that says so, and the ISP should know that blindly SIGNING
mail can create a huge problem for the DOMAIN.

Remember, the DKIM-BASE specifically says:

   The ultimate goal of this framework is to permit a signing
   domain to assert responsibility for a message, thus protecting
   message signer identity and the integrity of the messages
   they convey while retaining the functionality of Internet
   email as it is known today.

And in addition it says:

   INFORMATIVE NOTE:  Signing modules may be incorporated into any
   portion of the mail system as deemed appropriate, including an
   MUA, a SUBMISSION server, or an MTA.  Wherever implemented,
   signers should beware of signing (and thereby asserting
   responsibility for) messages that may be problematic.  In
   particular, within a trusted enclave the signing address might be
   derived from the header according to local policy; SUBMISSION
   servers might only sign messages from users that are properly
   authenticated and authorized.

So if the ISP or any middle ware along the path is going to blindly sign
mail, it is putting a responsibility on the DOMAIN that probably he didn't
want or atleast in the form he did not expect.   If you are going to allow
this, then the DKIM-BASE mandates and semantics regarding "responsibility"
and "message signer" and "signing domains" must change.  It would NO LONGER
protecting the FROM: address.  He is NOT in the picture any more because
ANYONE can signed with the NO-SSP proponents.

In any case, even in this scenario, the verifier is not going to really care
who SIGNS it. It is the about very basic LOGIC:

   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?

Its very simple.   The main threats are the above.

Finally, think about what you are creating if there is NO SSP possible for
the domain to declare.  Verifiers and MUAs or presenters can only assert one
thing:

    "This message was verified as being safetly delivered from
     the signing domain - ANYONE.COM."

[Note: yet at the same time, you want is to ignore any other
multi-signatture failure along the path.]

In this case, there can not be ANY association with the FROM: address
because it will create a FALSE illustion that the message is indeed
originating
and authored by the FROM: original author and that it was deemed "safe"
because some middle-ware, anyone.com, signed it.

In summary, if you have relaxed policies or no policies at all, a DKIM-BASE
only environment is going to create major problems for veriifiers and
ultimately for domains who may not even expected it in the first place!!

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

----- Original Message -----
From: "Dave Crocker" <[email-masked]>
To: "ietf-dkim" <[email-masked]>
Sent: Thursday, August 17, 2006 7:11 PM
Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy
designdecision

---

From: Frank Ellermann <[email-masked]>
Date: Fri, 18 Aug 2006 08:44:09 +0200

Hector Santos wrote:

> a DKIM-BASE only environment is going to create major
> problems for veriifiers

There would be several cases (obvious if I'm right, but I'd
be interested if I miss something):

1: 1st party signature from a known author, that's still good.
2: 3rd party signature from a known good relay, maybe better
   than heuristical timestamp line analysis (?)
3: signature from unknown parties or no signature is as before
   (without DKIM)

The lost case (without SSP) is an opportunity to reject mails
without 1st party signature claiming to be from authors who
normally sign everything (or let their ISPs do this for them).

Dave's proposal wasn't to remove SSP from the picture, but to
move the info with "delegations" from SSP to subdomains of the
author's domain.  Avoiding the threat explained by Jim.

I'm not hot about it, but it's a real threat, minimally it has
to be documented.  Like Scott proposed, 4408 also "solves" the
similar "shared host" issue by documenting it.  And those who
really don't get it can read an I-D explaining op=auth.  That
strategy could be also okay for SSP:

Just explain that "delegations" to a party not knowing about
this honour could be a very bad idea (if that party signs all
submissions down to the lowest grades of authentication).

A nice example I've seen in RFC 3958 (S-NAPTR):  the client
(for DKIM: the verifier) would ask the server (the designated
signer), if it's really supposed to sign on behalf of the
author, or if that's only a bad idea of the author.  Whatever
you (collectively) do, don't reinvent 3958 or 4408, use them
if that makes sense.

Frank

---

From: [email-masked] (Wietse Venema)
Date: Fri, 18 Aug 2006 11:26:53 -0400 (EDT)

>    (2) uses some other domain (that is associated with the operator doing the

I see where the confusion comes from, namely the scenarios where
both (1) and (2) involve a third party.

To clarify myself a little further:

In (1) the public key is listed under the author's domain, while
the secret key is operated either by 1a) the author's MTA or by
1b) the signing party's MTA.  This is what I called a first-party
scenario above. The verifier can't distinguish between 1a) and 1b)
except by parsing the contents of Received: message headers.

In (2) the public key is listed under the signer's domain, and the
secret key is operated by the signing party's MTA. There is no
relationship between author-domain and signing-domain. This is what
I called a third-party signature above.

In both (1) and (2) an assessment can be made on the basis of the
the signing-domain. If I get mail with a signature from some no-name
signing domain, then the author-domain (rfc822.from) is mostly
irrelevant. And if I actually do have reasons to trust the
signing-domain, then the author-domain is mostly relevant in case
(1), and mostly irrelevant in case (2).

	Wietse

---

From: Damon <[email-masked]>
Date: Fri, 18 Aug 2006 12:20:21 -0400

> (1), and mostly irrelevant in case (2).

Wietse,
Thank you for the clearest definition I have seen to this point.
What is the mechanism for depreciating (2)?

Regards,
Damon Sauer

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 18 Aug 2006 13:01:59 -0400

----- Original Message -----
From: "Wietse Venema" <[email-masked]>

> (1), and mostly irrelevant in case (2).

With all due respect, I'm speaking on the merits of the message, not the
person, this is nonsense.

Lets pick just one most highly probable exploitation:

What happens when 3rd party "Bad Guy" signs a DKIM-BASE valid message and
broadcast a million messages a million SMTP receivers with a 2822.From:
[email-masked]?

Using your signer-domain policy lookup, it will pass the test.

If you lookup the policy for porcupine.org, you are protected and a million
verifiers and their target users will not have to suffer the consequences.

Another highly probably abuse:

What happens when domain innocent.com who does not sign mail, and a 3rd
party "Bad Act" randomly selects innocent.com and signs mail, then broadcast
to a million receivers?

Using your signer-domain lookup, it pass the test and there is instant harm
done to innocent.com and the million receivers and users.

And so on.

---

From: [email-masked] (Wietse Venema)
Date: Fri, 18 Aug 2006 13:23:17 -0400 (EDT)

> What is the mechanism for depreciating (2)?

In case (1), when the trusted signer-domain matches the author-domain,
I might trust that the mail actually originates from the rfc822.from
domain. In case (2), when the trusted signer-domain is not related
to the author-domain, I might trust that mail was distributed by
the mailing list that I subscribe to, or that it was processed by
the malware removal service that I subscribe to.  Thus, in (2) the
author-domain (rfc822.from) is relatively unimportant compared to
the signing-domain; even in (1) its importance is only secondary.

	Wietse

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 18 Aug 2006 13:24:47 -0400

On Thursday 17 August 2006 16:50, Dave Crocker wrote:

> This mechanism already exists, is notably simpler than the one being
> discussed, and does not suffer the security hole that has been noted.
>
> Simply stated:
>
>      If the author's domain is to be used for assessment activities, then
> have the signature be made with a domain that is directly related to the
> author.

As was already discussed in the comments to the requirements draft, not all 
DNS providers give their customers the ability to do subdomain level NS 
delegation and so while that approach is good for those who can do it, it 
leaves out a portion of the potential user base.

There are a number of different areas where bought infrastructure (whether it 
be DNS or mail related) may have a significant impact on the deployability of 
DKIM.  In my opinion, the ability to provide a list of authorized operators 
to associate with a 2822.From is about giving flexibility to domain owners 
and operators.  

For DKIM-base the minimum DNS capability required is the ability to publish 
TXT records with an underscore in the name.  There are still some large DNS 
providers that do not meet this requirement.  If we can work out a reasonable 
way to publish a list of authorized signing domains (with all the appropriate 
cautions - which as I've said before I volunteer to write and keep writing 
until the WG agrees it's right) then SSP does not add any additional 
deployment requirements for outsourced DNS.  If we don't, then we either add 
subdomain NS delegation as an infrastructure requirement or key/selector 
update management as an operational complexity.

Not everyone runs their own dedicated infrastructure.  A scalable protocol 
includes (in my opinion anyway) scaling down to small domains too.

Scott K

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Aug 2006 10:31:50 -0700

> the signing-domain; even in (1) its importance is only secondary.

*very* nicely stated.

d/

-- 

  Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 18 Aug 2006 14:04:39 -0400

On Friday 18 August 2006 13:49, Michael Thomas wrote:
> Scott Kitterman wrote:
> >As was already discussed in the comments to the requirements draft, not
> > all DNS providers give their customers the ability to do subdomain level
> > NS delegation and so while that approach is good for those who can do it,
> > it leaves out a portion of the potential user base.
>
> Let's be very clear here: not every DNS provider has the ability to do TXT
> records either. Those small businesses, etc, should either pressure
> their providers
> or vote with their feet.

Agreed, but in the interests of deployability, we ought to keep the barriers 
to deployment as low as we reasonably can.  I already keep a list of name 
registrars and DNS providers that support TXT to make it easier for people to 
vote with their feet.  Let's not end up with someone having to do the same 
for subdomain NS delegation:

http://www.kitterman.com/spf/txt.html

I think that an explicit list of 'authorized' signers is reasonably doable 
with reasonable risk, but obviously opinions differ.

At this point, IIRC, it's a provisional requirement in the requirements draft.  
Given the concerns I think it's reasonable to leave it at provisional.  Let's 
leave it that way in the requirements phase and see what we can work out when 
we do the actual design work.  If it isn't practical or if the consensus is 
that it's to risky, we can, and should, drop it then.  

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 18 Aug 2006 14:12:33 -0400

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

> the signing-domain; even in (1) its importance is only secondary.

Where is all this TRUST coming from?

This is completely flawed logic subject to major high probability abuse, not
low probability.  How can you continue to ignore this?

I highly doubt you can prove otherwise, where I on the other hand I prove it
100% it is flawed.  I will have 100% trust, no "might trust" when I check a
2822.From: domain policy and it states a policy about how its mail is
tampered with (signed or not signed).  I'm not going to trust a 3rd party
signer for absolutely no reason whatsoever unless the OA domain vouched for
it in some "Allow List."   That would be a highly dangerous framework if
done in an uncontrolled manner and there is no way you can not prove it
would be exploitable.

Folks, we are continuing on this movement of allowing anyone to tamper, sign
or do whatever they want with mail, including adding/changing information to
headers that could destroy and change operations.  How people expect this to
be tolerated in a wide adoption is surreal!

---

From: Damon <[email-masked]>
Date: Fri, 18 Aug 2006 14:15:26 -0400

Wietse,

But this takes away my control over who can sign for me.
In my opinion there _must not_ be a way for someone to sign for _me_
without my approval. In this example you are showing what (1) might do
if they receive email from (2) which has nothing to do with the (1)
and has everything to do with (2). Having said that, there should be
no relationship between (1) and (2) in this example. Trusted or not
trusted... You are mixing the receiver and the sender policies.

Damon

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Aug 2006 11:23:04 -0700

Dave Crocker wrote:

>Michael Thomas wrote:
>>records either. Those small businesses, etc, should either pressure their
>>providers or vote with their feet.
>>    
>>
>
>
>1. Initial DKIM deployment relies upon support of DNS TXT records.  We either
>accept that or we start over.  Hence, any discussion of non-support of TXT
>records strikes me as counter-productive.
>
>2. How does support for TXT records affect the current discussion about
>Author-vs-Operator domain name, used for signing and assessment?
>  
>
Dave. I'm merely pointing out that lack of support by some DNS providers
for NS records is not a good argument since many/most do not support
using TXT records either.

       Mike

---

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

> What is the mechanism for depreciating (2)?

- DKIM signatures clearly indicate which domain can be held
   accountable for the message.

  o When can the 2822.From address be assumed to represent the
    recipient of this address?

  o Can 2822.From policy play a role in clarifying whether a
    2822.From address represents the recipient?

  o Can 2822.From policy assertions extend to other domains
    signing on behalf of the 2822.From address?

2822.From policy can offer assertions the 2822.From address is  
validated (it is being used by the recipient).  This validation can  
extend beyond just the immediate 2822.From domain.  This type of  
validation is commonly done by third-parties in many situations.  Key/ 
Selector assignments between a domain owner and an email provider, or  
zone delegations arrangements between an email-provider and a name- 
service provider represents _significantly_ greater administrative  
and procedural effort than just listing a domain in the 2822.From  
policy.  A policy listing tactic also allows a common signature to be  
applied by the email-provider for all their user accounts, even for  
those where the 2822.From is outside the signing domain.

Whether the designated domain protects the 2822.From address is  
something the domain owner of the email-address decides.  Any domain  
that is designated should be assumed to protect the 2822.From.  Any  
signing domain failing this protection should be removed with a  
complaint submitted to a certifying organization.  Unless 2822.From  
policy offers greater assurances the message is from the address's  
recipient, it provides little value.  If only signatures by the  
domain of the 2822.From can offer this assurance, then there is  
indeed less need for a 2822.From policy.

When a verifier discovers a policy that indicates all 2822.From  
address are always signed, exceptions must still be handled.  Even  
with a flag that asserts no other non-compliant services are used,  
cousin and look alike domains will remain a problem.  The greatest  
protective value of DKIM is achieved with annotations that indicate  
2822.From address is valid (per policy), and that this 2822.From  
address has been recognized as a prior correspondent.  This  
annotation needs to happen as often as possible for greater  
protection.  This annotation does not require the signing domain and  
the 2822.From domain match.  When not matching, but where the  
designated signing domain is well-known, this should offer even  
greater acceptance than a matching From/signing domain message coming  
from some obscure domain.

-Doug

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Aug 2006 11:36:53 -0700

Michael Thomas wrote:
>> 1. Initial DKIM deployment relies upon support of DNS TXT records.  We 
>> either accept that or we start over.  Hence, any discussion of non-support
>> of TXT records strikes me as counter-productive.
>> 
> Dave. I'm merely pointing out that lack of support by some DNS providers for
> NS records is not a good argument since many/most do not support using TXT
> records either.

Right.  I was trying to jump up a level and find out how this issue -- which you
did not introduce -- is relevant to the current topic.

In other words, I suggested that use of classic DNS sub-domains provides the
delegation features that cover the interesting cases for DKIM.

I continue to be unclear what is superior about having SSP invent a new
mechanism that creates security problems and additional administrative overhead.

d/
-- 

  Dave Crocker

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Aug 2006 11:46:29 -0700

>mechanism that creates security problems and additional administrative overhead.
Naively, I think there are some cases where the NS delegation mechanism 
leaves
something to be desired and hence the desire to have a more passive 
arrangement
between the domain holder and the signer. What I think we're finding is 
that there's
no free lunch and that the seemingly desirable passive mode suffers 
from  unacceptable
security problems. If it turns out that the passive mode of delegation 
is in fact active
after all (ie, requires agreement between domain holder/signer), then 
the requirement
should be dropped since you're exactly right: we already have a means to 
do that.

I think we're pretty much there, IMO. I'll let Stephen and Barry call 
that though.

       Mike

---

From: Damon <[email-masked]>
Date: Fri, 18 Aug 2006 14:51:06 -0400

> those where the 2822.From is outside the signing domain.

In this case the 2822 and the 3rd party have an established
relationship. However, in my opinion, in some cases I may only be able
to control this using a 2822 policy to supersede any 'common'
signature that may be in place.

> recipient, it provides little value.

Agreed.

>  If only signatures by the domain of the 2822.From can offer this assurance, then there is indeed less need for a 2822.From policy.

Unless 2822 is a "I Sign All"

> address are always signed, exceptions must still be handled.

>  Even with a flag that asserts no other non-compliant services are used,
> cousin and look alike domains will remain a problem.

How so?

> The greatest protective value of DKIM is achieved with annotations that indicate

This is a way to fix something that is broken through the use of
software. I will start writing some now... just in case.

The greatest possible protection comes from the 2822.From having
granular control over whom may sign and when and from where a
signature is required, . (which we can't do right now).

Regards,
Damon

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 18 Aug 2006 14:53:28 -0400

> using TXT records either.

True, but the universe of providers that support TXT, underscored names, and 
NS records for subdomains is smaller than that that support TXT and 
underscored names.  

I think it is a reasonable goal to have the protocol be broadly deployable.  
If the list of signing domains proves to be impractical when we do the 
design, then fine, lets drop it then, but I don't see the need to constrain 
ourselves now.

Scott K

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Aug 2006 11:52:41 -0700

>trusted... You are mixing the receiver and the sender policies.

 From a security protocol perspective, there is no way to prevent 
someone from wrapping a message in a signature. This was debated at 
nauseam by the OpenPGP and S/MIME Working Groups; it was the same 
rathole.

 From a security policy perspective, the message protocol can have a 
mark that says "only entity XYZ is authorized to sign this message". 
If another entity wraps that message in a signature, and does not 
remove that mark, the verifier can decide that the mark trumps the 
signature and consider the signature invalid. However, if another 
entity wraps that message in a signature and *does* remove that mark, 
there is nothing that the creator of the message can do. Also note 
that if another entity wraps that message in a signature and 
*replaces* that mark with one that says it is authorized, there is 
nothing that the creator of the message can do.

It sounds like what you and few other people want is an SSP policy 
that says "if you receive a message that is supposedly from this site 
(for some definition of "from") and it doesn't have the mark that 
says that XYZ is authorized to sign the message, assume the message 
is forged". Is that a correct summary of the requirement you see?
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 18 Aug 2006 14:55:24 -0400

On Friday 18 August 2006 14:36, Dave Crocker wrote:

> mechanism that creates security problems ...

What security problems are there with a list of authorized signing domains 
that are not equally applicable to the the NS delegation/operator signs with 
the author's domain approach?  I'm unclear about that.  Maybe we can help 
each other out.

Scott K

---

From: [email-masked] (Wietse Venema)
Date: Fri, 18 Aug 2006 15:14:13 -0400 (EDT)

Damon:
> without my approval.

I think it is a mistake to attach significance to the author-domain
(rfc822.from) unless there is a reason to trust the signing-domain
for this purpose (for example, scenarios 1a or 1b above). 

	Wietse

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 18 Aug 2006 15:11:05 -0400

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

> signature is required, . (which we can't do right now).

+1

I would like to think that the greatest protection is protecting your own
domains first. Then trying to protect remote domains from abusing your
system, thus protecting the remote domain as well.

Atleast 8-12% of my spam are senders using my own domains against my own
system

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Aug 2006 12:30:23 -0700

>for this purpose (for example, scenarios 1a or 1b above). 
Trust is probably the wrong concept here. If a domain advertises A records
in its DNS, I have some basis for belief that that is what they intend. 
It doesn't
say that I "trust" them per se (ie, I have no idea a priori whether they 
point
to something malicious or not). The same goes for SSP: if the From domain
says that it should have a valid signature, I may not trust the site, 
but I at least
have some belief that the name being asserted is intended if it 
verifies. (vs.
forged.) That's useful information regardless of whether I know much about
the site. Take, for example, all of these small regional banks being 
phished now...

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 18 Aug 2006 15:44:35 -0400

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>

> It sounds like what you and few other people want is an
> SSP policy that says "if you receive a message that is
> supposedly from this site (for some definition of "from")
> and it doesn't have the mark that says that XYZ is
> authorized to sign the message, assume the message

If that is what the OA domain (FROM) declares, sure.

But first he has to first declare he allows others to sign.

It can be relaxed (unrestricted), so you also can allow for an open-ended
3rd party signer policy which is what you guys want.

But we also want the option to control the potential abuse this open-ended
3rd party signing can caused as it been shown can and will happen.

The SSP people provide all the OPTIONS, the relaxed and the strong, the
restricted and unrestricted, including the relaxed to no-policy concept you
guys seem to want.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 18 Aug 2006 11:05:51 -0700

d/
-- 

  Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 18 Aug 2006 15:22:24 -0400

> is forged". Is that a correct summary of the requirement you see?

I would say that sums it up nicely.

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Fri, 18 Aug 2006 13:32:56 -0700

> the author's domain approach?  I'm unclear about that.  Maybe we can help 
With key delegation (either with NS, or by publishing a TXT record with
a public key that the signing operator uses), the operator signs using
the author's (or more generally the delegator's) domain name, and can
use i= to specify that the signature corresponds to the author's
address.  So it's possible to see that it's an author signature.  With
authorized signing domains, the operator signs using its own domain
name, and no association with the specific signing address (either the
local-part, or specification of which delegated domain) is possible.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Aug 2006 13:35:58 -0700

On Aug 18, 2006, at 11:36 AM, Dave Crocker wrote:

> I continue to be unclear what is superior about having SSP invent a  
> new mechanism that creates security problems and additional  
> administrative overhead.

Limiting 2822.From addresses allowed by specific customer accounts  
will involve coupling the incoming authentication scheme with a table  
of permissions applied by an incoming MTA extension.  This is indeed  
additional overhead, but it should be rather straight forward.  This  
mechanism will also reduce outbound spam and spoofing.  After all,  
signing messages may cause recipients to actually think the 2822.From  
is assured to be valid.  This additional mechanism fulfills this  
expectation.

There is often a user account page to allow address changes.  This  
page could be extended to also incorporate requests for outbound  
2822.From addresses to modify this 2822.From outbound restriction  
mechanism.  The addition of an address could spark a verification  
message confirmed by the account holder prior to this address being  
added to the permissions table.  This process is rather straight  
forward and only affects message acceptance by the outbound server.   
The verification process does not need to be limited to just  
addresses within the signing domain.

Imagine the administrative overhead needed when selectors, domains,  
and private keys are exchanged.  This might also be done by way of  
zone delegation as you suggest.  The customer will need to coordinate  
with their name service provider and with the email-service  
provider.  The customer will need to know how to apply the public  
key, or need to know how to generate the private key issued to the  
email-provider, or know how to delegate a zone to the name server  
controlled by the email-provider.  In addition to the exchange of  
keys, the entire path to the key is also needed regardless of the  
technique.  Once rather involved arrangements have been made, when  
this account sends any mail, different signature settings and private  
keys must be employed.  Just as with the 2822.From restriction  
mechanism, the outbound server must employ a different set of  
parameters based upon the account.

The difference is rather stark between what is involved to restrict  
permitted 2822.From addresses which benefits users by adding flexible  
spoofing protection, versus different signing arrangements.   
Exchanging zones or key parameters will involve far more  
administrative actions and overhead.

With domain designation, a name service provider can offer a simple  
fill in the blank list of domain names used for outbound mail  
services.  The name service provider may offer an added service that  
checks whether those domains are certified as being suitable for  
being a designated domain.  A domain that is suitable as a designated  
domain also means that the 2822.From within their signed messages are  
valid.  Most DKIM signing domains should want to take the effort to  
be certified as being suitable as a designated domain.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 18 Aug 2006 16:48:32 -0400

----- Original Message -----
From: "Paul Hoffman" <[email-masked]>
To: <[email-masked]>
Sent: Friday, August 18, 2006 4:07 PM

> Good. Glad we can have a shorter description.
>
> Why? To me, the above requirement makes sense even for
> someone who is going to sign their own messages.

The proposed 3PS (3rd party signer) options are:

 1   3PS NOT ALLOWED (what many of you guys did not want)
 2   3PS ALLOWED NO RESTRICTIONS (what you guys want)
 3   3PS ALLOWED WITH RESTRICTIONS
 4   3PS EXPECTED W/O RESTRICTIONS

The SSP-01 draft basically lacked the restrictions which nearly all the SSP
proponents agreed a delegation ideas was required since last year.

> If by "you guys" you mean DAC, it would be nice if you didn't
> put words in our mouths. To be specific, DAC hasn't made
> any statements on SSP because there is nothing to make
> statements on yet.

You should not make conclusions like this, but if the shoe fits...

By "You guys" I meant those who have shown to be nearly 100%consistently
opposed or resistant to any kind of 3rd party signature restrictions which
has been the numero uno basis division going back to MAILSIG.

I personally never argued against a open-ended 3PS, but it does come with
high risk for exploitable, therefore it seems to me to be prudent to allow
the option for domains who wish have restrictive domain signing practices.

I see no technical reason not to allow for strong/restrictive policies.

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 18 Aug 2006 17:06:44 -0400

On Friday 18 August 2006 16:32, Jim Fenton wrote:
> Scott Kitterman wrote:
> > What security problems are there with a list of authorized signing
> > domains that are not equally applicable to the the NS delegation/operator
> > signs with the author's domain approach?  I'm unclear about that.  Maybe
> > we can help each other out.
>
OK.  I got that.  Where I'm getting confused I guess is the process for 
deciding which domain the operator should sign with....

For reference, I'll differentiate between the two approaches by calling them 
the delegator approach (you describe above) and the authorized list approach.

In the authorized list approach, the operator receives a message with a 
certain 2822.From and the operator signs the message with their 
operator.domain.  Receivers then can (we postulate) query the SSP associated 
with the 2822.From and see what the author has to say about that.  This may 
result in the receiver treating the operator.domain signature as a first 
party signature.

The concern is that if the operator signs messages with that domain's 
2822.From that were not actually from an authorized user of that domain (e.g. 
it's a forged message) then this treatment is in error and a security risk.  
The solution to this concern is for the operator to determine if the message 
has been submitted by a source that is verified to be authorized to use that 
domain (what I referred to in other posts as controlled operations).  Since 
essentially no one does that today, this is a large change in operational 
paradigm and people are rightfully concerned about it being done incorrectly.

In the delegator approach, the operator receives a message with a certain 
2822.From and the operator signs the message with the 2822.From domain.  
Receivers then can see a first party signature.

It seems to me that the situation is essentially identical.  Operator gets a 
message with a certain 2822.From and has to decide what domain to sign with.  
In the delegator approach if the operator signs with the 2822.From domain and 
the message was forged, there is a security risk that is in my view (at least 
as well as I understand it) as bad if not worse than the authorized list 
approach.

Once again, the solution is to only sign e-mails with the 2822.From domain if 
the source of the mail is known to be authorized to use that domain (the 
controlled method of operation).

Either way the operator has to pick the correct domain to sign with and he has 
to do it via some kind of information other than just the 2822.From of the 
message.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 18 Aug 2006 17:12:51 -0400

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

> The "invalid" flag is not needed, but Hector will want to be able to
> list who signs even when the 2822.From is not validated.

Ok, I really don't care how you guys do it.

The bottom line is that DKIM-BASE is unprotected and fails to answer the
following questions:

I don't take away anyone else experiences, but I got 30 years of designing
multi-million dollars commercial products for corporations and for my own
business, with an sound expertise in software engineering, process control,
automation, simulation, fault analysis and foremost problem solving.  Never
mind all the mail design experience I have as well.  It doesn't take me very
long to see what the problems are going to be with a proposal such as
DKIM-BASE, where the exploitations will be, and while I keep in mind a
conservative considerations, what "feasible" solutions make work.

I think the above are very feasible "doable" design questions. Solve the
above questions with whatever protocol methods you like and I believe very
strongly DKIM will be very successful.

If there are things I don't see, I accept that. I would like to know what
they are thought.  But from I've seen in the last 2 years or so, in my
anti-spam project research sabbatical?  For DKIM-BASE, it needs an SSP
protection layer with the above minimum questions resolved. I can not in
good-faith see DKIM-BASE be "safe" when released into the wild without some
signature authorization protection.

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Aug 2006 10:49:15 -0700

Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Aug 2006 14:29:33 -0700

>    o  Are 3rd party signers or signatures allowed?

All this is answered by offering a list of designated domains and  
then indicating whether the list is exclusive.

>    o  Are 3rd party signers allowed to strip your original signatures?

This is redundant when a list of designated domains can be asserted  
as being exclusive.

This is a 2822.From policy, and as Jim has pointed out, when allowing  
a list, a means to signal whether the 2822.From addresses should be  
considered valid is needed.  I think being able to differentiate  
between scenario 1 and 2 is also important.  This introduces the  
concept of two flags "All" (signed) and "Only" (these used).

A desire to include sources where the 2822.From is not valid requires  
three flags:  "All", "Only", and "Invalid."

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 18 Aug 2006 13:07:10 -0700

>But first he has to first declare he allows others to sign.

Why? To me, the above requirement makes sense even for someone who is 
going to sign their own messages.

>3rd party signer policy which is what you guys want.

If by "you guys" you mean DAC, it would be nice if you didn't put 
words in our mouths. To be specific, DAC hasn't made any statements 
on SSP because there is nothing to make statements on yet.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 18 Aug 2006 16:58:26 -0700

> 2   3PS ALLOWED NO RESTRICTIONS (what you guys want)

I wish you'd stop putting words into people's mouths. There is a major 
disconnect
between your understanding of what is needed and as far as I can tell 
just about
everybody else's. Whether a third party signature is present or not is 
completely
irrelevant to the question of whether there is a valid first party 
signature. And it's
totally bogus to impugn that people have somehow shifted positions 
between now
and mailsig, and even if they did... so what?

       Mike

---

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

>the delegator approach (you describe above) and the authorized list approach.

If you know the source that authenticated with the submission -- which I 
think
we all agree is needed in the outsourced model -- then you only sign for 
that source's
domain. If it happens to correspond to one of the outside headers such 
as From:
or Sender: then you set i= to that address and everything works fine. 
You never
get into this cross-domain signature ambiguity that Jim brought up.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Aug 2006 13:41:09 -0700

On Aug 18, 2006, at 1:32 PM, Jim Fenton wrote:

>> domains  that are not equally applicable to the the NS delegation/ 
>> operator signs with  the author's domain approach?  I'm unclear  
>> about that.  Maybe we can help  each other out.
>
> With key delegation (either with NS, or by publishing a TXT record  
> with a public key that the signing operator uses), the operator  
> signs using the author's (or more generally the delegator's) domain  
> name, and can use i= to specify that the signature corresponds to  
> the author's address.  So it's possible to see that it's an author  
> signature.  With authorized signing domains, the operator signs  
> using its own domain name, and no association with the specific  
> signing address (either the local-part, or specification of which  
> delegated domain) is possible.

This is a valid point.

Either a listed domain must be assumed to have validated the  
2822.From address "as-if" the 'i=' syntax were used, or a flag must  
be included that indicates whether the 2822.From should be considered  
valid.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Fri, 18 Aug 2006 17:43:45 -0700

On Aug 18, 2006, at 5:04 PM, Michael Thomas wrote:

>>> With key delegation (either with NS, or by publishing a TXT  
>>> record with a public key that the signing operator uses), the  
>>> operator signs using the author's (or more generally the  
>>> delegator's) domain name, and can use i= to specify that the  
>>> signature corresponds to the author's address.  So it's possible  
>>> to see that it's an author signature.  With authorized signing  
>>> domains, the operator signs using its own domain name, and no  
>>> association with the specific signing address (either the local- 
>>> part, or specification of which delegated domain) is possible.
>>
>> OK.  I got that.  Where I'm getting confused I guess is the  
>> process for deciding which domain the operator should sign with....
>>
>> For reference, I'll differentiate between the two approaches by  
>> calling them the delegator approach (you describe above) and the  
>> authorized list approach.
>
> If you know the source that authenticated with the submission --  
> which I think we all agree is needed in the outsourced model --  
> then you only sign for that source's domain.

In the case of an authorized list tactic, the provider only has their  
key of their domain for signing messages.

For example: Sally Flower-Shop has an account with her provider  
ISP.com that validates all 2822.From addresses before accepting them  
in their outbound MTA.  This MTA signs with DKIM using their ISP.com  
domain.  When ISP.com added the 2822.Sender header, they found this  
caused complaints.  Sally has an account [email-masked] which is also  
the 2821.MAIL_FROM added to the message.  The message she wishes to  
use is:

From: [email-masked]
DKIM-Signature: d=isp.com ...

sally-flower-shop.com - 2822.From policy =
   designated domain list: isp.com, 2822.From='Valid'

Sally would like to have her customers see "sally@sally-flower- 
shop.com" marked as valid by an MUA that understand DKIM and  
2822.From policy.

Sally does not want her From address modified to be read:

  [email-masked] via [email-masked].

> If it happens to correspond to one of the outside headers such as  
> From: or Sender: then you set i= to that address and everything  
> works fine. You never get into this cross-domain signature  
> ambiguity that Jim brought up.

This also does not provide a result that most will understand.  Her  
customers expect to see messages from [email-masked].   
They don't know who [email-masked] might be.  Seeing a message sent via  
[email-masked] is not the desired outcome that Sally is happy seeing.

Adding a flag that indicates whether the designated domain protects  
the 2822.From provides the desired results.  Protected 2822.From  
addresses therefore offer valid 2822.From headers, even for those  
domains outside the signing domain.  This should be fairly practical,  
although not a common practice today.  This approach is still easier  
than other techniques used to assert that a 2822.From is valid.  A  
list of designated domains would require trusting ISP.com who signed  
the message, and sally-flower-shop.com who indicates trusting all  
2822.From addresses signed by ISP.com.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 18 Aug 2006 22:37:16 -0400

----- Original Message -----
From: "Michael Thomas" <[email-masked]>
To: "Hector Santos" <[email-masked]>

> I wish you'd stop putting words into people's mouths. There
> is a major disconnect between your understanding of what is
> needed and as far as I can tell just about everybody else's.
> Whether a third party signature is present or not is completely
> signature. And it's totally bogus to impugn that people have
> somehow shifted positions between now and mailsig, and even if
> they did... so what?

On the contrary, you have *not* change at all since mailsig and have made no
attempt to understand any argument made.  Your first three sentences above
proves it, especially the third worth repeating:

    Whether a third party signature is present or not is completely
    irrelevant to the question of whether there is a valid
    first party signature.

which proves:

    3PS ALLOWED NO RESTRICTIONS (what you guys want)

The fact is you have not being trying very hard to "tell" because there are
clearly people here who have expressed repeatedly the benefits of allowing
restrictive 3rd party policies, if so desired by the domain.

That's the kicker here, its all OPTIONAL yet, you are not even open to
making it an option.

So who is more open-minded here?

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 19 Aug 2006 04:00:00 -0400

On Friday 18 August 2006 20:04, Michael Thomas wrote:
> >>>domains that are not equally applicable to the the NS
> >>> delegation/operator signs with the author's domain approach?  I'm
> >>> unclear about that.  Maybe we can help each other out.
> >>
> >For reference, I'll differentiate between the two approaches by calling
> > them the delegator approach (you describe above) and the authorized list
> > approach.
>
Yes, but the fundamental operational problem will be to pick the correct 
domain to sign with.  You have to make that decision either way.  The basis 
upon which you make the decision is the same.  I agree that the result LOOKS 
less ambiguous with the NS delegation approach, but the fundamental security 
issue is don't pick the wrong domain to sign with and that's no different.

Scott K

---

From: "Hector Santos" <[email-masked]>
Date: Sat, 19 Aug 2006 09:21:54 -0400

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

> This is redundant when a list of designated domains can
> be asserted as being exclusive.

Yes, it can be redundant. But what if it is not exclusive?  This one I can
punt with, however, I highlighted it for this reason:

This has to do with MLS (Mailing List Servers or any middle ware for that
matter) and any mail tampering behavior they may exhibit and to help reduce
any "multi-signature" failure ambiquities.

In other words, if a domain has in its policy that 1st party signatures is
OPTIONAL, then it would be, in practice, possible for the MLS to 'cleanup'
any mess it may create.

However, it should be noted DKIM-BASE does have it stated that no signatures
MUST NOT be removed, even it was invalid which only adds to more ambiquity
because it may instantly promote failure as well as hide them.  It all
depends on the OA.

More on this below.

> This is a 2822.From policy, and as Jim has pointed out,
> when allowing a list, a means to signal whether the 2822.From
> addresses should be considered valid is needed.  I think
> being able to differentiate  between scenario 1 and 2 is
> also important.  This introduces the concept of two
> flags "All" (signed) and "Only" (these used).
>
> A desire to include sources where the 2822.From is not
> valid requires three flags:  "All", "Only", and "Invalid."

I understand the point and your suggestion.

But lets keep in mind that DKIM-BASE, including the fact that existing open
source code do already support the granularity (g=) and the identity (i=)
for the verification process.  So this logic is already part of the
DKIM-BASE signature HASH verification process.

The question, if I am still understanding the deviations of this thread, is
which domain to do the policy lookup.

It seems to me to hinge on two things:

  A) Whether there is a VALID 1st party signature, thus as
     some suggest, no need for a POLICY lookup, and

  B) Whether 3rd party is an important consideration, if present.

For example, suppose there are multi-signatures and lets throw in all the
discussed entities such as Sender:

  FROM: [email-masked]
  SENDER: mailinglist.com
  DKIM-SIGNATURE: d=ISP.COM; i=[email-masked];   # 3PS
  DKIM-SIGNATURE  d=company.com                    # 1PS

According to requirement #10, as long as the 1PS is valid, then there is no
need for any extra consideration (as far as DKIM is concern).

Now consider the issues:

If we ignore the state information regarding the presence of the 3PS, then
we lost the opportunity to protect the exclusive or any 3rd party
restricted/limited policy.  In other words, maybe there was no allowance for
ISP.COM to sign?

DKIM-BASE says, that as long as one signature is valid, then it passes the
DKIM-BASE test.

So what if the 1PS is not valid?

Remember, the scenario is that this is a mailinglist.com message, therefore
if company.com did sign the message, mailinglist.com might destroy the
integrity.

In this case, which SSP domain do we look at for the policy lookup?

I would hope that we still look at company.com's Policy.

Now lets consider at what ISP.COM might be doing when there is a 1PS already
present.

  a) Should it even add a 3PS?
  b) Should it remove the 1PS before adding a 3PS?

DKIM-BASE mandates option B is not to be allowed (no stripping of
signatures).

Therefore, the ISP is left to have smarts to either ADD one or NOT.  If the
1st party signature is invalid, it would seem to me that it must add one to
correct the message.

But whether it does or not, goes who left holding the bag to try to make
sense out of all this?

The verifier.

There are far too many scenarios to make heads and tail.

We need to keep it simple, the verifier needs to look at the original domain
policy to find out what was allowed to happen here or not and in my view, it
doesn't matter if there was a 1st or 3rd or both signature present or not.

My only point here is that company.com will need to learn how to use
DKIM/SSP if it wants to protect itself.  As you say, ultimately, the
presentation of such results is going to be able how the FROM is presented
to the end user.

If we want to discuss implementation details such as how mailinglist.com
(MLS) should be behave when it receives a company.com message or how the
ISP.COM (MSA/MTA) should behave when it sees two possible messages, one from
company.com and mailinglist.com representing the same OA domain, then I'm
ready for this.

---

From: Michael Thomas <[email-masked]>
Date: Sat, 19 Aug 2006 15:49:04 -0700

Scott Kitterman wrote:

>domain to sign with.  
If you know the submission authentication information, why is this hard?
They authenticate as [email-masked], that means I pick the key for bar.com (and
potentially foo if there's a g=). This doesn't seem like rocket science 
to me.

>You have to make thatd decision either way.  The basis 
No, the fundamental problem is that there's no way for a signer to relay 
that
information to the receiver via i= when you're  a third party.

       Mike

---

From: Scott Kitterman <[email-masked]>
Date: Sat, 19 Aug 2006 19:25:59 -0400

> They authenticate as [email-masked], that means I pick the key for bar.com
> (and potentially foo if there's a g=). This doesn't seem like rocket
> science to me.
>
No, I don't think it's that hard either.  One earlier objection, that seemed 
to me to be the key concern for some was that in order to make third party 
signing safe it would be necessary to pick a different domain to sign with.  
My point here is that first party with NS delegation or with an authorization 
list it's the same issue.  

I think we agree on that point then.

> >upon which you make the decision is the same.  I agree that the result
> > LOOKS less ambiguous with the NS delegation approach, but the fundamental
> > security issue is don't pick the wrong domain to sign with and that's no
> > different.
>
OK.  I didn't pick that up as the objection earlier (must be my density).  Let 
me think about that.  Off the top of my head, I don't see why it's a major 
issue, but I'll think about it.

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Sun, 20 Aug 2006 04:05:05 -0700

On Sat, 2006-08-19 at 15:49 -0700, Michael Thomas wrote:
> >> then you only sign for that source's domain. If it happens to 
> >> correspond to one of the outside headers such as From: or Sender:
> >> then you set i= to that address and everything works fine. You
> >> never get into this cross-domain signature ambiguity that Jim
> >> brought up.
> >   
> > Yes, but the fundamental operational problem will be to pick the
> > correct domain to sign with.

There are two possible secure modes.  One is where the service provider
has obtained either the private key/location, or has control of a
delegated zone to sign with matching signing and 2822.From domains.
Signing with an external domain must be restricted to domain validated
accounts.

Perhaps each account must offer key/location information to validate the
use of that domain.  Offering zone delegation information is easily
spoofed. This still leaves the 2822.From validation when signing for a
different domain.  What is required to safely use the i= syntax that
indicates the 2822.From is valid?  Reliance upon per user keys will be
difficult to scale and will generally risks DNS when done on a large
scale.

The policy based mode saves several steps, and unnecessary use of
different keys.  This mode simply places a general restriction at the
outbound MTA on the 2822.From address per account.  The message is
signed with the service provider's normal key under their domain.  This
2822.From restriction mechanism is required even when a matching signing
domain is available.  This mechanism must exist to ensure the valid use
of the 2822.From address.

In either mode of operation, a 2822.From validation/restriction step is
required to ensure the 2822.From address is valid at the outbound MTA.
Matching the signing domain with the 2822.From domain is an unnecessary
extra step.  Exchanging key/location information adds no additional
security when this 2822.From restriction is applied by the provider.

> If you know the submission authentication information, why is this
> hard? They authenticate as [email-masked], that means I pick the key for
> bar.com (and potentially foo if there's a g=). This doesn't seem like
> rocket science to me.

Verification of foo and bar should be viewed as separate issues. If an
account is being arranged that acts as a relay of corporate servers,
then a key/location approach should be used.  The provider would still
need to ask whether the 2822.From addresses are assured to be valid.

To allow their outside employees access to the provider's general
account facilities, this provider could also be added as a designated
provider when 2822.From validation restrictions are in place at the
provider.  When this restriction is in place, then the 2822.From policy
could assert the addresses are "Valid".

> > You have to make that decision either way.  The basis upon which you
> > make the decision is the same.  I agree that the result LOOKS less
> > ambiguous with the NS delegation approach, but the fundamental 
> > security issue is don't pick the wrong domain to sign with and
> > that's no different.
>   
> No, the fundamental problem is that there's no way for a signer to
> relay that information to the receiver via i= when you're a third
> party.

A "2822.From is valid" assertion can also be conveyed by the 2822.From
policy as well as the i= syntax.  When there is a list of designated
domains in the 2822.From policy, and the 2822.From is asserted as not
being valid, then only signatures with matching domains could override
the "Invalid" assertion made in the policy.

On the other hand, if only DKIM signing domains that restricted the
outbound 2822.From address (pending receipt-verification) were listed,
then it would be safe for their 2822.From policy to assert that all
2822.From addresses are valid.

Signatures with a matching domain could override the Valid/Invalid
assertion made by the 2822.From policy.  The 2822.From Valid/Invalid
assertion would only apply when the 2822.From and signing domains do not
match.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Sun, 20 Aug 2006 22:34:13 -0700

> issue is don't pick the wrong domain to sign with and that's no different.
When using the "authorized signing domains" approach, the signer uses
its own domain name, not that of the domain doing the delegation.  I
don't see where there is a choice for the signer to make (which is also
the source of the ambiguity).

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Aug 2006 07:57:35 -0400

On Monday 21 August 2006 01:34, Jim Fenton wrote:
> > domain to sign with.  You have to make that decision either way.  The
> > basis upon which you make the decision is the same.  I agree that the
> > result LOOKS less ambiguous with the NS delegation approach, but the
> > fundamental security issue is don't pick the wrong domain to sign with
> > and that's no different.
>
We had been discussing the need to segregated authenticated traffic (where 
authorization to use the 2822.From has been established) from other traffic 
being signed by use of a subdomain.  This is to avoid issues like your 
mailing list concern.  The authorized signing domain would be the subdomain 
that the operator has designated for the purpose.  

Scott K

---

From: Damon <[email-masked]>
Date: Mon, 21 Aug 2006 10:40:06 -0400

> is forged". Is that a correct summary of the requirement you see?

I am glad you put a question mark at the end.

It took me a while to read through this can of worms, but for every
argument against the optional flags that myself, Hector, and I few
others are looking for, I see contrary arguments that only bolster the
point that these thing we are hinging on are OPTIONAL. Just because
they are OPTIONAL does not automatically make them irrelevant nor
unnecessary. I have yet to see an argument that shows where they are
technically unsound in everything but statistically insignificant
situations, which in my opinion is the litmus test for dismissal.
I really did not want to see this turned into an 'us' against "ya'll"
discussion. (ya'll _is_ a word in Georgia) But arguing against
something that a) Is technically sound b) Would benefit many entities
c) is OPTIONAL, to me, sounds like ya'll are being contrary just to be
contrary. And if the 'Ya'll' shoe fits... please don't take this as a
personal attack. I have always been impressed with the amount of
intelligence in this group and I consider each and every person in it
my friend and colleague.

I can't name many people in this group that are less eloquent than I,
so I have chosen a few points to high lite. Also, it seems to me that
people are not really reading what Hector is taking a lot of time and
thought in putting forth. While I may not always agree with approach,
I mirror his technical points. Hector and I have not always seen eye
to eye in technical discussions in the past, but I believe (and have
experienced) that both of us submit to better arguments. I notice that
neither of us is budging on this point.

-Hector Santos-

-Michael Thomas-

I wish you'd stop putting words into people's mouths. There is a major
disconnect between your understanding of what is needed and as far as I can tell
just about everybody else's.

-- I am baffled by the above statement.

-Hector Santos-

-- I could not have said this better myself... hence the cut and paste.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Aug 2006 05:58:05 -0700

On Sun, 2006-08-20 at 22:34 -0700, Jim Fenton wrote: 
> > correct domain to sign with.  You have to make that decision either
> > way.  The basis upon which you make the decision is the same.  I
> > agree that the result LOOKS less ambiguous with the NS delegation
> > approach, but the fundamental security issue is don't pick the wrong
> > domain to sign with and that's no different. 
>    

Do not consider policy listing domains to be a type of authorization.
This mode of operation depends upon other assertions that might be made
in this policy.  A more accurate term would be designated domain.

When a provider selectively uses other domain keys for signing, there
must be 2822.From domain permissions applied per account.  This process
must place either a local-part@domain or just domain restriction on
these accounts.

When a signing domain fails to ensure the local-part@domain is valid,
then a local-part restriction must be made by the account holder now
restricted to a domain.  Without a local-part@domain restriction made by
the account holder, the i= syntax should not indicate the 2822.From is
valid.

When the provider _always_ ensures the local-part@domain allowed per
account is valid, there is no potential for ambiguity regardless what
domain is selected to sign.  When policy designates such a signing
domain that always ensures valid 2822.From addresses, their signature
can be safely treated "as if" it was a first party signature.

When the provider _always_ ensures the local-part@domain is valid, then
i= syntax or policy can always indicate the 2822.From is valid.  At some
point a valid local-part@domain restriction mechanism per account must
be in place regardless which domain signs, or the 2822.From is
ambiguous.  In either case, the recipient is trusting the signing domain
to ensure the accuracy of the 2822.From validity assertions.

-Doug

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Aug 2006 08:28:21 -0700

>I am glad you put a question mark at the end.

But you didn't answer: is that a correct summary. (And, if not, is 
there a summary that looks like this one?)

>unnecessary.

True. However, even if they are optional, they have to be fully 
specified in order for people in the WG to understand if they are 
relevant or necessary. The parts that I miss in this thread is: "for 
this particular optional statement of policy, what is the recipient 
of that policy message expected to do? What are the requested to do?"

I see people who supposedly agree with each other about the policy 
appear disagree on the required and requested response to the policy. 
Some of that is because the tone of the messages is "this is obvious" 
(which it is not), and some of it is because there are long-winded 
discussions of the usefulness of the messages that don't concretely 
say what the recipient should/must do.

Note that the above summary of this one point has such a 
specification: "assume the message is forged".

--Paul Hoffman

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Aug 2006 09:25:31 -0700

On Aug 21, 2006, at 8:28 AM, Paul Hoffman wrote:

>>> It sounds like what you and few other people want is an SSP  
>>> policy that says "if you receive a message that is supposedly  
>>> from this site (for some definition of "from") and it doesn't  
>>> have the mark that says that XYZ is authorized to sign the  
>>> message, assume the message is forged". Is that a correct summary  
>>> of the requirement you see?
>>
>>

This summary is not complete.

A list of designated domains can optionally indicate the following:

  - The 2822.From is valid when signed by a designated domain.

  - The domains authorized to sign for the 2822.From domain when  
Exclusivity flag is set.

  - When the list is empty and the Exclusivity flags is set, that no  
mail is sent from the domain.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Aug 2006 09:38:03 -0700

On Aug 21, 2006, at 8:34 AM, Dave Crocker wrote:

> Paul Hoffman wrote:
>> appear disagree on the required and requested response to the  
>> policy. Some of that is because the tone of the messages is "this  
>> is obvious" (which it is not), and some of it is because there are  
>> long-winded discussions of the usefulness of the messages that  
>> don't concretely say what the recipient should/must do.
>
> For the case of mail that is signed, I am still waiting to hear why  
> it is not sufficient to have a third-party use a a sub-domain of  
> the preferred (author, or whatever) domain name.

The domain or subdomain of a signature must still restrict the use of  
the 2822.From address to enable validity assertions.  When the  
signing domain restricts 2822.From address to those validated per  
account, then this address can be asserted valid.  The validity of  
the address can be asserted by i= syntax or by a 2822.From policy  
with respect to designated domains.

> Hence, the signing practices requirement would only exist for  
> unsigned messages.

The requirement for signing practices would exist whenever the domain  
of the signature does not match the domain of the 2822.From address.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 21 Aug 2006 12:35:36 -0400

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

> of that policy message expected to do? What are the requested to do?"

This is long discussed in both SSP-01 and DSAP-00:

http://tools.ietf.org/html/draft-allman-dkim-ssp
http://tools.ietf.org/wg/dkim/draft-santos-dkim-dsap-00.txt

In addition, the following table created long discussions since last year to
serve as a basis for discussion. Nearly everyone felt it helps in
structurely what needs to be discussed and was.

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

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

In addition, the current open SendMail source code (dkim-milter-0.5.1) has
current support only for:

    Signature Optional (o=~ DKIM_POLICY_SIGNSOME)
    Signature Expected  (o=- DKIM_POLICY_REQUIRED)
    Signature Not Expected (o=. DKIM_POLICY_NEVER)

The 3rd party restrictive policy DKIM_POLICY_AUTHORITY (o=!) as defined in
SSP-01 is not SUPPORTED. There is no action for it.

This can only be assumed to be based on the idea that 3rd party or middle
ware signing is not be restricted.

One question that keeps coming back to me is if all this push back is to
avoid more code changes that is already in the DKIM public API vaults?

> (which it is not),

We can agree they are not obvious to everyone, but what is?   Rest assured,
the most obvious will be first thing exploited whether we recognize it now
or not.

DSAP address obvious exploits that will occur in a DKIM-BASE only
environment that follows fundamental security and protocol consistency
considerations.

The first obvious problem starts during initial deployment with the
reception of non-signed messages which may have an domain expectation to be
signed.  Is that not obvious?

Other obvious exploits:

  - No mail is expected to be distributed,
  - Mail is signed (good or bad) and its not suppose to be, and
  - you didn't expect other people to be signing for you.

Now those are obvious exploitations because unless you do anything to
control it or make a protocol declaration that they are not threats, they
will cause inconsistencies that will make DKIM less valuable.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Aug 2006 08:34:13 -0700

Folks,

Paul Hoffman wrote:
> discussions of the usefulness of the messages that don't concretely say
> what the recipient should/must do.

For the case of mail that is signed, I am still waiting to hear why it is not
sufficient to have a third-party use a a sub-domain of the preferred (author, or
whatever) domain name.

Hence, the signing practices requirement would only exist for unsigned messages.

d/
-- 

  Dave Crocker

---

From: "Hector Santos" <[email-masked]>
Date: Mon, 21 Aug 2006 12:49:04 -0400

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

> Hence, the signing practices requirement would only exist

This is already covered in the public SendMail DKIM source code
(dkim-milter-0.5.1) which has current support only for:

The 3rd party restrictive policy DKIM_POLICY_AUTHORITY (o=!) as defined in
SSP-01 is not support. There is no action for it and the philosophy
continues.

This is what's needs to be addressed.

Are we really dealing with a backward compatibility issue here more than
anything else?

In my opinion, I am taking both a precautionary and proactionary approach to
all this.  From a precautionary standpoint, I think it is the burden on
those who don't want 3PS restrictions to show why there are not threats when
open-ended 3PS signings are done.  From a proactionary standpoint, I believe
I have shown via the DSAP draft a low cost effective solution to address
some of the most common sense DKIM-BASE protocol inconsistency issues.

I really don't know what else, how else can be done.  I concur that when a
1st party signature is validated, that the "threats" level is reduced when
3rd party signatures.  But we have no evidence whatsoever that this removes
potential exploits.   The solution is to provide the OPTION to those who do
not want expect it.  We can't not eliminate all the risk, but we can
optimize risk with a lost cost effective solution.

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Aug 2006 10:17:18 -0700

On Aug 21, 2006, at 9:35 AM, Hector Santos wrote:
>> relevant or necessary. The parts that I miss in this thread is:  
>> "for this particular optional statement of policy, what is the  
>> recipient of that policy message expected to do? What are the  
>> requested to do?"
>
> In addition, the following table created long discussions since  
> last year...

There are problems created using this verifier action matrix,  
especially when a list of designated domains creates another category  
of domain.  Rather than asserting what the verifier should do, there  
is greater clarity in describing what the signer does.

A Third-Party signature can be confusing when it may or may not be  
included within a list of designated domains.

The following policy assertions based upon signer actions encompass  
1st Party and all designated domains, however the 1st Party signature  
syntax can override the policy Invalid/Valid assertions for the  
2822.From address.

"All" initial messages are signed for the 2822.From domain.
"Only" compliant sources are used that do not damage signatures.
"Invalid" 2822.From addresses are permitted.

All+Only = DKIM Signer Complete
All = DKIM signer Extended

>     Signature Optional (o=~ DKIM_POLICY_SIGNSOME)

Any policy without All+Only assertion.
A policy that indicates All assertion should then include only common  
services.

>     Signature Expected  (o=- DKIM_POLICY_REQUIRED)

A policy that indicates All+Only

>     Signature Not Expected (o=. DKIM_POLICY_NEVER)

An empty list and All+Only assertion would indicate no mail sent.

Adding a flag that asserts that DKIM is never used would be trumped  
by a valid signature.  This may provide minor value for handling  
domains that do not use DKIM and somehow find a reason to make this  
policy assertion.

Should policy include:

"Never" signs with DKIM policy assertion?

> The 3rd party restrictive policy DKIM_POLICY_AUTHORITY (o=!) as  
> defined in SSP-01 is not SUPPORTED. There is no action for it.

The All+Only flags and designated domain list covers this use.

> This can only be assumed to be based on the idea that 3rd party or  
> middle ware signing is not be restricted.
>
> One question that keeps coming back to me is if all this push back  
> is to avoid more code changes that is already in the DKIM public  
> API vaults?

By including a list of designated domains, greater flexibility can be  
achieved while still retaining all the prior states.  The flags that  
offer the least benefit would be:

  - "Invalid" as listing a domain could assert an assumption that the  
2822.From are valid for the designated domain.

  - "Never" as there seems to be little justification for making the  
assertion.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Mon, 21 Aug 2006 13:56:24 -0400 (EDT)

> sufficient to have a third-party use a a sub-domain of the preferred (author, or

For example, domain example.com stores their dedicated public key
under a dedicated domain something.example.com.

Even when the signing operation itself is outsourced to a third
party, using a dedicated signing key+domain for [email-masked]
gives better protection than a scenario where the same shared,
unrelated, key+domain signs mail from thousands of different domains.

With a shared signing key+domain, if one of those thousands of
domains mis-behaves, all the other domains could suffer from the
bad reputation of that shared signing key+domain.

Thus it's better to avoid shared signing key+domain scenarios.

> Hence, the signing practices requirement would only exist for

Indeed. With a dedicated signing key+domain as discussed above,
the rfc822.from is protected by a first-party signature only. All
other signatures are by definition third-party, and vouch for the
signer, not the rfc822.from.  Signing practices can tell us if mail
without first-party signature is a possible forgery, regardless of
whether or not that mail has a third-party signature.

	Wietse

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Aug 2006 11:39:27 -0700

On Aug 21, 2006, at 10:56 AM, Wietse Venema wrote:

> Dave Crocker:
>>
>> For the case of mail that is signed, I am still waiting to hear  
>> why it is not sufficient to have a third-party use a a sub-domain  
>> of the  referred (author, or whatever) domain name.
>

Not necessarily.  This would still trust the provider to restrict  
permissions for the arranged domain by the account accessing the  
outbound MTA.  If the provider always ensured the 2822.From had been  
validated per account, then use of a common domain still retains  
protection for the 2822.From address.

> bad reputation of that shared signing key+domain.

Some abuse is normally allowed of any source, especially large  
domains serving millions of users.  Due to replay issues, a DKIM  
signature alone may not offer effective acceptance criteria.  Sharing  
the services of such a domain could be relatively safe, and provide a  
means for the 2822.From to be annotated as valid without needing to  
make key/domain arrangements, provided the provider includes a  
mechanism that limits accounts to only validated 2822.From addresses.

> Thus it's better to avoid shared signing key+domain scenarios.

This would really depend upon how well the signing domain was managed.

> Indeed. With a dedicated signing key+domain as discussed above, the  
> rfc822.from is protected by a first-party signature only.

Not necessarily.  There still must be a restriction placed on the  
2822.From address per account somewhere in the path of the message.

> All other signatures are by definition third-party, and vouch for  
> the signer, not the rfc822.from.

Not necessarily.  It is possible to validate the 2822.From address  
outside the signing domain.  Such domains that first validate all  
2822.From addresses can be considered equivalent to a 1st party domain.

> Signing practices can tell us if mail without first-party signature  
> is a possible forgery, regardless of whether or not that mail has a  
> third-party signature.

It can also indicate whether the 2822.From should be considered  
valid.  Although policy can indicate which domains are expected to  
sign for the 2822.From, without an ability to discern whether the  
2822.From address is valid, there would be little benefit obtained  
going to the effort of checking the policy.

-Doug

---

From: <[email-masked]>
Date: Mon, 21 Aug 2006 12:56:30 -0400

I have a customer oxley.com who wants to use my offered dkim signing
service, are you intending that I create an subdomain called
signer.oxley.com and sign from there administrating thousands of public
keys for these entities? Much simpler to sign as coxmail.com with only
one public key signing for thousands of customers.

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Dave Crocker
Sent: Monday, August 21, 2006 11:34 AM
To: [email-masked]
Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy
designdecision

Folks,

> discussions of the usefulness of the messages that don't concretely
say
> what the recipient should/must do.

For the case of mail that is signed, I am still waiting to hear why it
is not
sufficient to have a third-party use a a sub-domain of the preferred
(author, or
whatever) domain name.

Hence, the signing practices requirement would only exist for unsigned
messages.

d/
-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Aug 2006 14:15:46 -0700

Folks,

> Thus it's better to avoid shared signing key+domain scenarios.

Based on some conversations today, I think we need to do a better job of
distinguishing keys from reputations (identities).

It is even more important that we carefully distinguish between internal
operational policies, versus the information that a signer must make public.
Good protocol design makes it imperative that we separate these and that we make
the portion visible to -- or, rather, imposed upon -- other protocol
participants be absolutely as small as possible.

(I am using the term "reputation" as a placehold for the wide range of analyses
that can be performed, once one believes that a claimed identity is valid.)

Keys
----

The allocation of private keys provides a means of controlling who can create
signatures, under a particular domain name.  The selector is used to support
multiple simultaneous keys, under that single domain name.  Selectors can be
used for something as simple as introducing a new key to replace an old one, or
as complex as support of an army of mobile users who do not submit mail through
the organization's servers.

The critical point about such a set of keys/selectors is that they all map to a
single domain name and that that single domain name is the basis for reputation
analysis.

Reputation
----------

The d= parameter in a DKIM signature field defines the domain name that is to be
used for reputation assessment.  The signer chooses what domain to use.  It does
not matter how many different keys exist for that domain or how many different
instances of the signing function there are -- that is, it does not matter if
lots of different folk are signing under that same, single name.  If they all
produce the same domain name, their messages share the reputation of that single
domain name.

An email signing administration can choose a variety of schemes for supporting
name assignment to the d= parameter.  It can have something as simple as one
name for all mail, with only one instance of the signing function.  It can have
something as complex as a different d= parameter for every author of content.
That is entirely up to the folks administering the signature service.

The question is what does the signer need to communicate to a validation site,
for the validation site to be able to make a useful assessment?

The answer is:  a validly signed domain name.

That's all.

If the signer wants to have assessment be based on different reputations, such
as for messages authored by different customers of the signer or messages
authored by different departments in the signer's organization, then the signer
needs to use different d= values.

Scope
-----

I claim that this is all that is needed, for DKIM signed mail, in terms of
determining what identity to use for assessment of the message and to determine
whether the use of that identity is "authorized".

For a signed message, anything beyond this is really trying to dive into the
complex arena of reputation subtleties.  While these are, of course, important,
they are vastly more complex than ensuring valid signatures.

In other words, the job of DKIM is to deliver a valid identity to an assessment
mechanism.

The signer determines what identity is to be delivered and DKIM makes sure that
the assessment mechanism whether the assertion of that identity is valid.  DKIM
needs to support fine-grained naming, so that signers have a wide-range of
choices for they way their different signing identities can be evaluated.
However DKIM does not have a role in deciding what those choices can or will be.

How the assessment service decides to use different names is a matter that falls
under reputation and accreditation.  My reading of the charter says that that is
out of scope.

d/

-- 

  Dave Crocker

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Aug 2006 17:36:07 -0400

On Monday 21 August 2006 17:15, Dave Crocker wrote:
...
> The question is what does the signer need to communicate to a validation
> site, for the validation site to be able to make a useful assessment?
>
> If the signer wants to have assessment be based on different reputations,
> such as for messages authored by different customers of the signer or
> messages authored by different departments in the signer's organization,
> then the signer needs to use different d= values.
>
>
>
> Scope
> -----
>
> determining what identity to use for assessment of the message and to
> determine whether the use of that identity is "authorized".
>
> For a signed message, anything beyond this is really trying to dive into
> the complex arena of reputation subtleties.  While these are, of course,
> important, they are vastly more complex than ensuring valid signatures.
>
> In other words, the job of DKIM is to deliver a valid identity to an
> assessment mechanism.
>
> The signer determines what identity is to be delivered and DKIM makes sure
> that the assessment mechanism whether the assertion of that identity is
> valid.  DKIM needs to support fine-grained naming, so that signers have a
> wide-range of choices for they way their different signing identities can
> be evaluated. However DKIM does not have a role in deciding what those
> choices can or will be.
>
> How the assessment service decides to use different names is a matter that
> falls under reputation and accreditation.  My reading of the charter says
> that that is out of scope.
>
If I read what you've written correctly:

> In other words, the job of DKIM is to deliver a valid identity to an
> assessment mechanism.

> How the assessment service decides to use different names is a matter that
> falls under reputation and accreditation.  My reading of the charter says
> that that is out of scope.

What you are saying is that DKIM-base is all that is in scope for the working 
group.  Last time I read the charter, that isn't what it said.  What am I 
missing here?

What would you say is in scope for DKIM-SSP?

Scott K

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Aug 2006 15:32:41 -0700

On Aug 21, 2006, at 2:15 PM, Dave Crocker wrote:

> Based on some conversations today, I think we need to do a better  
> job of distinguishing keys from reputations (identities).
>
> It is even more important that we carefully distinguish between  
> internal operational policies, versus the information that a signer  
> must make public. Good protocol design makes it imperative that we  
> separate these and that we make the portion visible to -- or,  
> rather, imposed upon -- other protocol participants be absolutely  
> as small as possible.
>
> (I am using the term "reputation" as a placehold for the wide range  
> of analyses that can be performed, once one believes that a claimed  
> identity is valid.)

In addition to the signing domain and key selector, DKIM can signal  
the validity of the 2822.From address.  These are separate identities  
that can be assessed and used to accrue a behavioral history.  The  
assertion of 2822.From validity can be done via i= syntax or by way  
of a policy assertion of a signing domain outside the 2822.From domain.

DKIM does not prevent replay, but might be effective at indicating  
when the source of an identity appears suspicious.  DKIM does not  
identify who created the message envelope and thus does not identify  
the entity responsible for abusive sending.

Certification of account handling, signing practices, and the  
validation of the 2822.From might be where reputation becomes  
relevant and practical.  This could convey whether the signing domain  
ensures the validity of the 2822.From address, the frequency an  
2822.From address within an outside domain is re-confirmed, how  
accounts are established, how quickly abuse reports are resolved, etc.

> Keys
> ----
>
> The allocation of private keys provides a means of controlling who  
> can create signatures, under a particular domain name.  The  
> selector is used to support multiple simultaneous keys, under that  
> single domain name.  Selectors can be used for something as simple  
> as introducing a new key to replace an old one, or as complex as  
> support of an army of mobile users who do not submit mail through  
> The critical point about such a set of keys/selectors is that they  
> all map to a single domain name and that that single domain name is  
> the basis for reputation analysis.

It seems too early to know how key selectors might be used, whether  
reputation accrues to just the parent domain, and the role of the  
2822.From address.  Perhaps a convention is established for  
transactional messages where the right-most label in the key selector  
is named "safe".  Selectors might be used to partition the domain's  
messages.  Not all users within a domain are equally trustworthy.   
This trust may be partitioned by using the 2822.From local-part,   
different selectors, or perhaps an r= parameter.  It seems premature  
to speculate on how reputation is best applied or how the domain's  
traffic is partitioned, identified, and reported.

Per the DKIM charter:
,----
|To prevent this task from becoming unwieldy, several related topics are
|considered out of scope for the DKIM working group. These topics
|include:
|
|* Reputation and accreditation systems. While we expect these to add
|  value to what is defined by the DKIM working group, their development
|  will be separate, and is out of scope for the DKIM working group.
'----

-Doug

---

From: Damon <[email-masked]>
Date: Mon, 21 Aug 2006 18:55:49 -0400

> traffic is partitioned, identified, and reported.

This is _exactly_ the direction I would like to go, and so far, I
don't see a technical issue with it as long as we _do not_ say, 3rd
parties can sign for me even if I don't want them to. Otherwise, you
can put as many selectors as you want, but without being able to say
that, depending on the situation an unsigned or possibly signed
message from you can be trumped by a 3rd party signature- Handing all
the spades to the unsavory.

Regards,
Damon Sauer

---

From: Michael Thomas <[email-masked]>
Date: Mon, 21 Aug 2006 16:17:09 -0700

Damon wrote:

> parties can sign for me even if I don't want them to.

Nobody to my knowledge has taken that position.

       Mike

---

From: "J.D. Falk" <[email-masked]>
Date: Mon, 21 Aug 2006 17:13:45 -0700

+1

  [ . . . ]
> needs to use different d= values.
  [ . . . ]
> In other words, the job of DKIM is to deliver a valid identity to an assessment

Makes sense to me, though I suspect we'll need to repeat this a few 
times before everyone groks it.

+1

Keep it simple.

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

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Aug 2006 17:19:14 -0700

>> It seems too early to know how key selectors might be used, 

No it doesn't.

A selector adds one level of name granularity.  So does a regular sub-domain name.

If the purpose of an extra level of granularity is semantic, then it belongs in
the actual name.  That is, it belongs in the d= string.

The construct of selector is for a different purpose.  It is an administrative
construct, not a semantic one.

>>   Selectors might be used to partition the domain's messages. 

It has been a while since I have quoted my favorite system's engineer.  His
expertise in considering trade-offs has often been undervalued, so I tend to
make a point of crediting him in these circumstances:

     "We could do it, but it would be wrong."
                   -- R. Nixon; WG Tapes.

If you want to partition among messages -- and by this, I assume that what was
actually meant was to label messages in logically different bins, for the
purpose of permitting differential assessments (reputations) -- then that is
what sub-domains are for, in the d= parameter.

Let me stress a basic point:

     The instant that a selector is used semantically, it becomes
     worthless for its primary purpose, namely support of multiple
     keys for the same d= domain name.

> Not all users within a domain are equally trustworthy.

Quite true.  And if the signer wants to distinguish among "users" by having
different signatures, then use different d= sub-domains.

>> different selectors, or perhaps an r= parameter.

No.

d/

-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Aug 2006 19:04:22 -0700

On Aug 21, 2006, at 5:19 PM, Dave Crocker wrote:

> If the purpose of an extra level of granularity is semantic, then  
> it belongs in the actual name.  That is, it belongs in the d= string.

There are likely practical considerations that will affect the  
general application of this rule.

Big-Bank.com has a few thousand email-addresses assigned to employees  
and specialized services all under their parent domain of:

  [email-masked]

Now Big-Bank.com is told this must change to conform to a "semantic"  
requirement of someone's reputation system using the d= parameter  
within the DKIM signature header.  : (

A major advantage offered by DKIM was-

DKIM Base:
,---
|o the message signature is written as a message header field so that
|  neither human recipients nor existing MUA (Mail User Agent)
|  software are confused by signature-related content appearing in
|  the message body,
'___

The added security afforded by DKIM was absolutely transparent.  That  
goal must now be abandoned to support a semantic for a reputation  
service that changes the email-addresses being used?

When Big-Bank.com is coerced into using subdomains to partition their  
messages, their customers will see more complex domain names within  
the email-addresses and might become confused by what they see.

Perhaps this might be subdomains like:

  [email-masked]
  [email-masked]
  [email-masked]
  [email-masked]
  [email-masked]
  etc.

A profusion of subdomains along with the extra text now must be  
carefully examined.  This added profusion will likely make Big- 
Bank.com an easier phishing target.  Will Big-Bank.com's customers  
know the difference between a '.' and some other character used in a  
domain name?  Things like the following may go unnoticed.  Poor grandma.

  [email-masked]
    instead of
  [email-masked]

> The construct of selector is for a different purpose.  It is an  
> administrative construct, not a semantic one.

True.  The key selector is allowed to use multiple labels.  One of  
these labels could be dedicated to the purpose of segregating the  
domain without affecting the critical appearance of their email- 
address, or requiring everyone to understand that-

[email-masked]
  is now really the same person at
[email-masked]

When people already recognize an email-address, changing the email- 
address will not improve a recipient's trust with respect to who is  
now sending them messages.

> It has been a while since I have quoted my favorite system's  
> engineer.  His expertise in considering trade-offs has often been  
> undervalued, so I tend to make a point of crediting him in these  
> circumstances:
>

     “You see things; and you say, 'Why?'
      But I dream things that never were; and I say, 'Why not?'
                      -- George Bernard Shaw

> If you want to partition among messages -- and by this, I assume  
> that what was actually meant was to label messages in logically  
> different bins, for the purpose of permitting differential  
> assessments (reputations) -- then that is what sub-domains are for,  
> in the d= parameter.

   The d= parameter remains unseen in the DKIM header, which is good.

   For the sake of a reputation assessment, this changes the  
appearance of the address, which is not good.

>      keys for the same d= domain name.

This basic point is very wrong.  The s= parameter already supports  
multiple labels.  Only _one_ label is needed to enable multiple keys  
for the same d= domain.  For example:

   d=example.com

   s=summer._safe
   summer._safe._domainkey.example.com key

   s=winter._safe
   winter._safe._domainkey.example.com key

   s=fall._promo
   fall._promo._domainkey.example.com key

   s=spring._employee
   spring._employee._domainkey.example.com key

These are examples where the email-address is allowed to remain  
unchanged, multiple keys are provided for the same domain, and yet  
separate reputation assessments remain possible.  Here are examples  
of three categories of messages _safe, _promo, and _employee.  The  
base domain is likely well recognized as their trademark.  Flooding  
this domain name with subdomains reduces the clarity of the email- 
address.

> Quite true.  And if the signer wants to distinguish among "users"  
> by having different signatures, then use different d= sub-domains.

Which subdomain or domain is more trustworthy?  Your scheme demands  
email-addresses be modified to comply with a reputation scheme.  Why  
not have the reputation scheme achieve the same goal as that of DKIM  
and remain transparent?  DKIM will require annotation to convey the  
signature results, reputation can be included within this  
annotation.  The address does not need to change.

>>> different selectors, or perhaps an r= parameter.

If DKIM does not offer a means to assure the validity of the  
2822.From address, then DKIM will have missed an important goal.   
Knowing who you are communicating with is an extremely important  
aspect of trust.  This trust is not improved by changing the email- 
addresses being used.

-Doug

---

From: Damon <[email-masked]>
Date: Mon, 21 Aug 2006 19:46:01 -0400

> Nobody to my knowledge has taken that position.
I'm sorry, I smacked my forehead so hard, I rendered myself
momentarily unconscious.

Maybe I over-simplified... I try not to be long winded.
Replace with -> "If I do not have the ability to suggest to a receiver
how they should treat my signature, signed or unsigned, or how a third
party signer should be treated if signing on my behalf."

Regards,
Damon

---

From: [email-masked] (Wietse Venema)
Date: Mon, 21 Aug 2006 22:29:14 -0400 (EDT)

>   [email-masked]

No, the SIGNER uses different d= domains in the signature HEADER.

	Wietse

---

From: Dave Crocker <[email-masked]>
Date: Mon, 21 Aug 2006 19:41:29 -0700

...
> No, the SIGNER uses different d= domains in the signature HEADER.

RIght.

Folks keep confusing the domain name in the rfc2822.From field (or
rfc2822.Sender field) with what is in the DKIM-Signature field's d= parameter.

Folks need to stop confusing these.

d/

-- 

  Dave Crocker

---

From: Douglas Otis <[email-masked]>
Date: Mon, 21 Aug 2006 22:48:58 -0700

> No, the SIGNER uses different d= domains in the signature HEADER.

When DKIM fails to offer a means to assure the validity of the 
2822.From address, then an important goal has been missed.  The use of a
subdomain for signing removes an ability to indicate with the i= syntax
that the 2822.From is assured to be valid.

It is possible to list a subdomain (or any other domain) as a designated
domain within the 2822.From policy.  This policy could assert the listed
designated domains assure the 2822.From addresses are valid ("as-if"
they were a 1st Party domain).  In this case however, accessing policy
is required to obtain an assurance the 2822.From is valid. : (

On the other hand, a convention using the s= selector still allows a
means to partition the domain, allow the signature to directly make an
assertion that the 2822.From is valid, and offer multiple keys per
d=domain.  This is achieved without needing to obtain policies or
altering the email-address.

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 22 Aug 2006 05:54:09 -0400

---- Original Message -----

> In other words, the job of DKIM is to deliver a valid identity
> to an assessment mechanism.

To me, SSP is an protocol assessment mechanism. I view it as an assessment
of the proper and expected protocol usage and consistency.

But even then, don't you think this changes or alters the goal of what's
describe in the DKIM-BASE pending standard?

   The ultimate goal of this framework is to permit
   a signing domain to assert responsibility for a message, thus
   protecting message signer identity and the integrity of the messages
   they convey while retaining the functionality of Internet email as it
   is known today.  Protection of email identity may assist in the
   global control of "spam" and "phishing".

That "responsibility assertion" is an really important idea here especially
when we currently have allowance for just about anyone to sign on behalf of
the message author name along the path from point A to Z.  Are we really
protecting in the OWNER represented by the messaging identity?  Or are just
protecting the signer?  If so then why are we allowing for a resigner to
break what could be a legitimate signed originally signed message?

To me, all DKIM-BASE does is protect the integrity of the message against
any tampering.  It does not protect how that message was created, well, it
can if we want to throw in some "X-Mailer:" header in the signature hashing,
etc, but that isn't the point.  DKIM-BASE is just attempting protect the
digital signature of the message.  The tie-in to "authorship" or any other
important Mail System concept, is the hashing of these elements so that they
are not altered along the path.

> How the assessment service decides to use different names
> is a matter that falls under reputation and accreditation.
> My reading of the charter says that is out of scope.

{Scratching head, pondering, so why is he bringing it up?}

I personally do not see R/A systems making a judgment on how a message is
done but rather that its coming from a vouched known source.

I go back to the Patrol Officer analogy:

A Patrol officer sees your Driver's license has expired or you left it at
home, and you got some good looking legs.  The cop "might" just let you with
a warning this time around.    A R/A can "save" its customers from mishaps.

But 99% of the times or lets just say it is expected police protocol and
practice for a traffic stop that if there is a problem with your Driver's
license; the photo, the sex, age, height, etc, it is simply not quite
consistent which what he is seeing in reality, at this point, there is
increase scrutiny and by Police Protocol and Practice he should radio the HQ
database (i.e., Reputation Service) to find out if there anything bad or new
to find out about you or the vehicle you are driving.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Aug 2006 07:33:01 -0700

On Tue, 2006-08-22 at 05:54 -0400, Hector Santos wrote:
>
> But 99% of the times or lets just say it is expected police protocol
> and practice for a traffic stop that if there is a problem with your
> Driver's license; the photo, the sex, age, height, etc, it is simply
> not quite consistent which what he is seeing in reality, at this
> point, there is increase scrutiny and by Police Protocol and Practice
> he should radio the HQ database (i.e., Reputation Service) to find out
> if there anything bad or new to find out about you or the vehicle you
> are driving.

Most bad actors are not fools. Playing a hard nose cop will block vastly
more legitimate email than spoofing attempts.  Due to look-alike and
internationalization issues, the ultimate solution can not rely upon
failed concepts that attempt to impose a problematic authorization
scheme. Who can afford an increase in phone calls and complaints anyway?

2822.From policy is best used to indicate which 2822.From addresses are
valid.  With DKIM and this policy, the number of messages that can be
discerned to have a valid 2822.From address can greatly increase without
imposing hardships.  Policy does this by permitting autonomous
administration.  When the MUAs annotate messages that are both found in
the Address Book, and appear to be signed with valid 2822.From
addresses, look-alike and internationalization exploits will have been
thwarted.  This prevention does not rely upon a reputation or an
authorization scheme.

A great deal of legitimate email will not be assured to have a valid
2822.From address.  Over time that may change.  Nevertheless, DKIM can
restore trust in the 2822.From address, especially for critical
messages.  This trust must not be based upon visual examination.  The
bad actors are too good at creating forgeries.  The MUA must implement
the final check at the highest resolution possible.  The MTA can not
achieve the same level of scrutiny.

Perhaps a 2821.MAIL_FROM policy of a designated domain list can provide
an association with the DKIM signing domain.  These associations could
improve upon the MTA triage process without DoS concerns, but not as a
type of authorization scheme and without the badges.  : )
 
-Doug

---

From: Damon <[email-masked]>
Date: Tue, 22 Aug 2006 10:45:58 -0400

> type of authorization scheme and without the badges.  : )

Wow, that was a lot of typing to try and convince me that everyone
hates more phone calls and trouble tickets and therefore we should
punt.
Are you saying that you see NO value in it or so little value that it
would be statistically insignificant?
Remember- it is OPTIONAL.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Aug 2006 09:03:47 -0700

> Remember- it is OPTIONAL.

The 2822.From policy assertions should describe actions of the signing
domains.  A suggestion has already been made to differentiate between
scenario 1 and 2 in the requirements draft.  It should be clear whether
all initial messages are signed AND whether common services are also
being used.  The difference could represent the extreme measures a
phishing target may find necessary at this time.

All + Only = DKIM Signer Complete (no non-complaint services)
All        = DKIM signer Extended (some non-complaint services)

When translated to signer actions, Hector argues for an assertion that
indicates the signer Never signs, and a flag that indicates designated
domains do not validate the 2822.From address.  Both of these assertions
offer little benefit from a protective standpoint, and might be debated
on that basis.  The more important aspect of this debate is centered
upon understanding a difference between suggesting verifier actions and
clarifying signer actions.

-Doug

---

From: Jon Callas <[email-masked]>
Date: Tue, 22 Aug 2006 09:57:54 -0700

> that the 2822.From is assured to be valid.

Doug.

Section 5.4 of DKIM-base says:

    5.4  Determine the header fields to Sign

     The From header field MUST be signed (that is, included in the
     h= tag of the resulting DKIM-Signature header field).

How does this not handle your objection? What you are saying ("When  
DKIM fails to offer a means to assure the validity of the 2822.From  
address...") is categorically false. DKIM *REQUIRES* you to assure  
the validity of the 2822.From address.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Aug 2006 10:06:48 -0700

A DKIM base compatible option?

When subdomains or other domains are used to sign the message, a  
significant utility is lost.  This utility allows the 2822.From  
address to be assured on a per message basis independent of a policy  
assertion.  To overcome this limitation, adopting the r= parameter  
could replace the lost ability for asserting the 2822.From is valid  
or invalid on a per message basis.  When r=1, the signing domain  
asserts the 2822.From address has been validated.  An r=-1 assertion  
indicates the 2822.From should not be assumed validated.  The value  
of r=0 or not appearing in the signature then defers the 2822.From  
validity assertions to the 2822.From policy.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Aug 2006 10:11:39 -0700

On Aug 22, 2006, at 9:57 AM, Jon Callas wrote:

>> 2822.From address, then an important goal has been missed.  The  
>> use of a subdomain for signing removes an ability to indicate with  
>> the i= syntax that the 2822.From is assured to be valid.
>
> Doug.
>

Applying a signature and ensuring the 2822.From header can not be  
modified is not equal to having validated that the account sending  
the message represents the recipient of that 2822.From address or  
that this account's use of the 2822.From address is valid.  Being  
included in the signature's hash is not the same as having validated  
the associated content.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Tue, 22 Aug 2006 15:59:00 -0700

> that the operator has designated for the purpose.  
Sorry, having trouble keeping the context of the discussion right.

This could be done, but dilutes the simplicity argument that motivated
the Authorized Signing Domains approach in the first place.  Formerly
the ISP just signed using their own domain name; now they must create a
subdomain for each of their customers, publish keys there, and sign each
using the proper subdomain?  Or do they sign using i=@cust49.isp.com and
d=isp.com perhaps?

But there is a residual problem.  Suppose [email-masked] is a
subscriber to this list and someone spoofs a message from
[email-masked] to the list.  [email-masked] accepts the
message and sends it to isp.com, their Authorized Signing Domain, and it
is signed and sent.  Is the signature from jdoe (the author) or
ietf-dkim (the mailing list)?  Without Authorized Signing Domains, you
could tell by looking at the local-part of i=.  But now you can't.  I
think this is an important distinction, even if it only applies in a
subset of use cases.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Tue, 22 Aug 2006 16:43:54 -0700

On Aug 22, 2006, at 3:59 PM, Jim Fenton wrote:

> Scott Kitterman wrote:
>>
>> We had been discussing the need to segregated authenticated  
>> traffic (where authorization to use the 2822.From has been  
>> established) from other traffic being signed by use of a  
>> subdomain.  This is to avoid issues like your mailing list  
>> concern.  The authorized signing domain would be the subdomain  
> This could be done, but dilutes the simplicity argument that  
> motivated the Authorized Signing Domains approach in the first  
> place.  Formerly the ISP just signed using their own domain name;  
> now they must create a subdomain for each of their customers,  
> publish keys there, and sign each using the proper subdomain?  Or  
> do they sign using i=@cust49.isp.com and d=isp.com perhaps?

An ISP might use subdomains to isolate different _categories_ of  
sources as denoted by the d= parameter.  One such use might be for  
sources where the 2822.From domains are _not_ validated.

Validated 2822.From domains could use:
   dkim-signature: d=isp.com ...
   From: some-validated@from-domain

The email-lists might could use:
   dkim-signature: d=lists.isp.com
   From: some-non-validated@from-domain

> message and sends it to isp.com, their Authorized Signing Domain,  
> and it is signed and sent.

For the ISP to assure the 2822.From, would need to base their  
signatures and identity assertions upon this account authentication.   
The ISP should have an account specific for the mailing list.  The  
account should determine what domains are used to sign the message  
and what assertions are applied.  If the intent is have the base  
ISP.com domain represent only validated 2822.From addresses, then a  
different signing domain would be needed for use by mailing-lists.   
In this case, perhaps all mailing-lists are signed with the  
lists.isp.com domain.

> Is the signature from jdoe (the author) or ietf-dkim (the mailing  
> list)?

Account authentication must make the determination. If the message is  
being relayed without direct authentication, then perhaps a subdomain  
for this use might be relay.isp.com.

> Without Authorized Signing Domains, you could tell by looking at  
> the local-part of i=.  But now you can't.  I think this is an  
> important distinction, even if it only applies in a subset of use  
> cases.

This is an important point and why the 2822.From policy may need to  
make this 2822.From validity assertion explicit.

-Doug

---

From: Damon <[email-masked]>
Date: Tue, 22 Aug 2006 19:59:37 -0400

> think this is an important distinction, even if it only applies in a

Should mailing lists sign messages?
If they did, wouldn't it be a 3rd party sig?
If we were able to say "No third party can sign for me" it would stop the spoof.

Regards,
Damon Sauer

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 22 Aug 2006 20:08:52 -0400

Jim,

I consider the baseline situation where verifiers receiving non-signed
messages and what you would use from the minimum 2822 headers available to
extract the domain policy information.

What will that be?

In other words, if you have:

  Received:
  From:
  To:
  Subject:
  Date:

and no other DKIM fingerprints, what do you use to get the DKIM signing
practice?

---

From: <[email-masked]>
Date: Tue, 22 Aug 2006 20:22:13 -0400

"This could be done, but dilutes the simplicity argument that motivated
"the Authorized Signing Domains approach in the first place.  Formerly
"the ISP just signed using their own domain name; now they must create a
"subdomain for each of their customers, publish keys there, and sign each
"using the proper subdomain?
my problem exactly
thanks,
Bill

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 23 Aug 2006 01:14:57 -0400

> "using the proper subdomain?

Except I don't think that's necessary.  Just that controlled traffic be 
segregated from uncontrolled traffic.  This could be a value added service.

Scott K

---

From: Graham Murray <[email-masked]>
Date: Wed, 23 Aug 2006 07:31:34 +0100

> Should mailing lists sign messages?

The problem with mailing lists is that there are 2 identities which it
might be useful to verify. First that the message did actually come
via the mailing list, and the second is the identity of the person
submitting the message to the mailing list. So it might be useful for
both the author and mailing list to sign the messages.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 23 Aug 2006 10:57:53 +0100

I think I've caught up on this thread, but have a couple of
questions/comments.

1. Jim/Mike's scenarios allow for a spoofed message to be inserted
between the supposed originating domain (company.com) and the common
signing domain (mailinglists.com). For the verifier, why is this
so different? Such messages could in any case be inserted inside
company.com - so is it only a matter of the likelihood or is there
some qualitative difference that could damage the verifier?

2. (Overlaps with #1.) The scenarios nicely demonstrate how the
verifier can't tell exactly what's happened, but don't seem to
say exactly how the bad actor benefits, nor what damage might
occur to the verifier. Be good to document that explicitly. (This
might be just my ignorance of course, but its not very clear to
me.)

3. If we could describe what we do/don't want to happen as a
security requirement that'd be good to include in the requirements
document (along with the problematic scenarios).

4. If there is a requirement to achieve similar functionality via
delegation of keys, then we (as a WG) need to be very clear about
how those keys are managed, or else have to provide a convincing
argument that such management is not our problem. (Any such key
management being non trivial.) It is at least arguable that the
overall system would be less secure due to problems with key
management, when compared to problems arising from corner cases,
or bad behaviour happening, prior to delegated signing.

Stephen.

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 23 Aug 2006 07:51:53 -0400

Hi Stephen,  welcome back from your vacation! :-)

There is a lot to be said here, but I think it all comes down to answering
the baseline scenario that "looks and feels" like Jim/Mike's scenario; the
baseline scenario when there is no DKIM signature header:

    From: [email-masked]
    Sender: [email-masked]
    To: [email-masked]
    Date: Wed, 23 Aug 2006 01:14:57 -0400
    Subject: Important new stuff!

How or what will a verifier us to extract policy information from this
message transaction?

What domain are we protecting in the above available header block?
company.com? mailinglist.com?  We can't look up the ISP.COM records because
we don't see any information about it.

Should we use mailinglist.com?  From the company.com standpoint,
mailinglist.com is not a signer.  The verifier does not know that, so should
it use mailinglist.com or the Sender: domain?  Where is the inherent trust
there to suggest mailinglist.com was acting of the behalf of company.com?

If we use company.com, we will see there is a 3PS signing requirement
associated with the designated ISP.COM.  With no DKIM signature header
present, we have strong evidence it is bad.

There is really much more to say here, but it really comes down to the above
because what we decide here should also apply when there is a signature
present.  Or does the policy lookup rule change when there is a DKIM
signature header available?

----- Original Message -----
From: "Stephen Farrell" <[email-masked]>
To: "Jim Fenton" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 23, 2006 5:57 AM
Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy
designdecision

---

From: Jon Callas <[email-masked]>
Date: Wed, 23 Aug 2006 10:59:30 -0700

> included in the signature's hash is not the same as having  
> validated the associated content.
>

Forgive me for misunderstanding. You're asking then, for something  
that is out of scope of what DKIM claims to do and that DKIM *cannot*  
do. If you have an ISP that forges email in your name, domain-level  
signing is orthogonal to that problem.

So let's just stop wrapping ourselves around that axle.

	Jon

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Aug 2006 11:30:55 -0700

On Aug 23, 2006, at 10:59 AM, Jon Callas wrote:

> that is out of scope of what DKIM claims to do and that DKIM  
> *cannot* do. If you have an ISP that forges email in your name,  
> domain-level signing is orthogonal to that problem.

Indeed the DKIM signature does not directly validate the 2822.From  
address.  However there is a means for the signing domain to  
communicate an assurance of the 2822.From address through the use of  
the dkim-signature i= syntax.  A similar assertion is equally  
plausible within the 2822.From policy record.  This assurance could  
be deferred to the 2822.From policy when the signing domain is a  
subdomain or otherwise outside the 2822.From domain.  A mechanism for  
verifying proper use of the 2822.From address could be analogous to  
steps taken when registering an email-certificate or when subscribing  
to a mailing-list.

Providers that implements such a mechanism can ensure messages signed  
for by a specific domain are not forging anyone's email-address.   
Allowing DKIM to assert that the 2822.From address is assured valid  
is clearly beneficial.  This mechanism alone will impact the amount  
of spam coming through bots, which represents approximately 70% of  
the overall sources.  An assertion by the DKIM signer made by way of  
DKIM semantics or a 2822.From policy statement *can* be done.   
Knowing which provider properly assures the 2822.From address may  
require some type of domain assurance council.  : )

-Doug

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 23 Aug 2006 14:44:03 -0400

On Wednesday 23 August 2006 14:34, Jim Fenton wrote:
> I believe they should.
I believe they should too.

> Yes.
Yes.

> But the signature from the mailing list adds value (it says the message
> is really from the list), so many domains would not want to express that
> policy.  What's needed is a way to unambiguously interpret the role of
> the signature (i.e., is it a signature representing the author or the
> mailing list) and the SSP delegation proposal has made that ambiguous in
> some cases.

Which is what the proposal to segreagate controlled MSA operations in a 
separate subdomain achieves.  Since the signing domain is not readily visible 
to the user, there is no user interface issue to worry about.

I'm still missing why we are still arguing about this.  The spec definitely 
needs some language about controlled versus uncontrolled signing and the 
unsuitability of uncontrolled signing for SSP delegation.  I don't know what 
more we need.  I've already volunteered to write the language when we get to 
that part of the process (last I checked we are still on requirements, but 
it's been hard to tell recently).

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 23 Aug 2006 14:49:09 -0400

On Wednesday 23 August 2006 14:41, Jim Fenton wrote:
> [changed the subject line because this is straying a bit from the
> delegation topic]
> Hector Santos wrote:
> > messages and what you would use from the minimum 2822 headers available
> > to extract the domain policy information.
> >
> > What will that be?
> >

> According to draft-allman-dkim-ssp-01, section 2.2, it would be the
> From: address (or the first From address in the rare case that there is
> more than one).  However, that's just a proposal at this point, but
> since you ask "what do you use", that's what I would use.
>

Agree it's From, but if there are multiple From's then I think you have to 
query them all up to some processing limit (set to prevent DoS).  If you just 
check the first one and there are MUA's the display multiple ones or perhaps 
just the last one (I don't know, I've never actually seen a multi-From 
message) then you've left a hole.

Scott K

---

From: Jim Fenton <[email-masked]>
Date: Wed, 23 Aug 2006 12:07:57 -0700

> some qualitative difference that could damage the verifier?
"Damage the verifier" makes it sound like we're breaking the verifier or
something, but I don't think that's what you mean.  The problem is that,
absent SSP Delegated Signing Domains (SSP DSD), it's fairly easy for the
verifier or a later agent to determine the role of a signature by
matching the i= address (signing address) against other header fields in
the message.  With SSP DSD, it's no longer possible to do that, because
the signing address bears no relationship to other header fields in the
message, other than that it was authorized by the author's SSP.

Some workarounds have been proposed whereby the signing domain uses
subdomains to work around some (but not quite all) of this ambiguity.  I
believe that this removes some of the supposed simplicity that was the
motivation for SSP DSD in the first place.
> might be just my ignorance of course, but its not very clear to
In at least some cases, bad actors and good actors may share the same
domain.  Suppose a bad actor shared the same domain with a good actor
and a mailing list.  The bad actor could spoof a message to the mailing
list from the good actor.  If the domain uses SSP DSD, the signature
would not have any way of indicating whether it was on behalf of the
good actor or the mailing list.  The "damage" to the verifier is the
interpretation of a mailing list signature as being an author signature
from the good actor.
> document (along with the problematic scenarios).
See above.
> or bad behaviour happening, prior to delegated signing.
I thought we covered key management threats in the threat analysis
already.  In any case, if it's not covered adequately, it belongs in
either the threat analysis or in -base, because there is no key
management in SSP.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 23 Aug 2006 11:41:40 -0700

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 23 Aug 2006 15:18:22 -0400

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

>> Jim Fenton wrote:
>> mailing list) and the SSP delegation proposal has made that
>> ambiguous in some cases.

> more we need.

+1

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 23 Aug 2006 15:25:48 -0400

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

Subject: Where to look for the signing practice

> From: address (or the first From address in the rare case that there
> is more than one).  However, that's just a proposal at this point,
> but since you ask "what do you use", that's what I would use.

Agree.  But I'm not sure we had strayed, since the same method would apply
for a non-signed message as for a 3rd party signed message.

That was the point of my message.

Unless I completely misread, the scenario was such that a suggestion was
made that maybe we should look at the 3rd party signing domain policy or
sender versus the original domain policy.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 23 Aug 2006 11:34:43 -0700

I believe they should.
Yes.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Aug 2006 00:46:12 +0100

Hi Jim,

Jim Fenton wrote:
> The problem is that,

Sure. But so what? The verifier never really knows what went on before
signing and we haven't really defined signing roles.

> motivation for SSP DSD in the first place.

I didn't follow all of those details, but I'd agree that, in general,
and in this case, a complex delegation mechanism is worse than none.

> interpretation of a mailing list signature as being an author signature

But that depends upon how the verifier has (mis)interpreted the
signature - something I thought we generally try to steer away from.
The proper interpretation (at the dkim level) of the "SSP DSD"
signing case is surely that company.com nominated isp.com to sign
for company.com and that that's all correct (or not, whatever). A
verifier that thinks it means that isp.com says that it got the
signed-bytes directly from company.com seems to be making
decisions/assumptions at the wrong layer.

I'd still like to see a concrete case of something that can happen
here that cannot happen if no "SSP DSD" mechanism is defined.

Sorry for being obtuse, but I'm concerned that we're maybe eliminating
a requirement that has some support (unless those supporting it have
been convinced already), and where the basis for elimination is
something that can happen in any case (which basically seems to be
that funny things can happen before signing and the verifier will
be blissfully ignorant).

>> document (along with the problematic scenarios).

Nope that didn't do it for me. I was thinking of something along
the lines of (a readable version of) "singing practices MUST be
sufficiently simple, that expected sets of independent practices
do not interfere with one another, nor with current email practices",
and then follow up explaining the corner case of company.com and
mailinglists.com as per the thread. (The fact that its maybe quite
hard to write down what we want to protect here, may be meaningful
IMO - it might mean we're not sure what we're protecting?)

> either the threat analysis or in -base, because there is no key

Sure, but my worry is that we define SSP so that we push people
to delegate keys (as opposed to signing) and then get (properly)
criticised for not supplying the required key management. This
isn't really a comment on the SSP requirements, but rather a
worry about the consequences of how we resolve some of these
issues, (and a definite wish to not have to start figuring
which existing key management scheme(s) to pick for dkim key
delegation;-)

S.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Aug 2006 17:04:13 -0700

> some qualitative difference that could damage the verifier?

If I am understanding what you've written, we probably *do* need to distinguish
between signing within the originating ADMD, versus signing later, such as when
re-posting the message by a mailing list.

Still, I think your basic point is that a signer might or might not validate the
rfc2822.From field.  DKIM does not take a position on this.

So, the degree of enforcement for the content of *any* signed field is not
stated as part of DKIM's specification.

> occur to the verifier. 

Isn't it as simple as:  A signer might have practices that permit header fields
to have invalid content?

> document (along with the problematic scenarios).

Certainly would be good for us to be clear about!

> or bad behaviour happening, prior to delegated signing.

You lost me here.

DKIM says nothing about key management now.  Why does this need to change, for
the particular case of having keys used by someone in another ADMD?

d/

-- 

  Dave Crocker

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Aug 2006 17:22:13 -0700

> criticised for not supplying the required key management. 

Whether to delegate DNS administration of a name that is used for signing, or
merely to delegate a private key that is used for that name, is a matter of
administrative choice by the owner of the domain.

In other words,

1) I can keep all the DNS administration, including for the sub-domain and
including key generation and publishing; so I merely tell the outside service
what domain name to use and what private key to use; or

2) I can register a DNS NS record for the sub-domain and let the outside service
do all the key and related DNS work themselves.

There is nothing that we are doing that dictates or even suggests which choice
to make.  Nor, I believe, should there be.

As for getting "(properly) criticised for not supplying the required key
management", I have no idea what you mean.

d/
-- 

  Dave Crocker

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Aug 2006 01:28:48 +0100

> stated as part of DKIM's specification.

Yes, that sounds right. DKIM-base says how to sign stuff but really
says little about what that stuff might mean.

> Isn't it as simple as:  A signer might have practices that permit header fields

If so, then that doesn't seem to be dependent on the "SSP DSD"
mechanism. I've no position on whether that's right or not, but
haven't understood what the "SSP DSD" mechanism changes.

Agreed.

> the particular case of having keys used by someone in another ADMD?

My earlier mail to Jim may have explained. But saying it again another
way can help so:

If we support delegation of signing ("SSP DSD") then I can easily
see how to do that (by including the delegatee name in some SSP
practice statement). If however, we don't support delegation of
signing, then it may be more likely that folks make more use of
delegation of keys. Once we start down the road where delegation
of keys is common (or nearly so), then there's an onus on us to
say how to do that, and there's a lot of complexity there. For
example, what if domain1 tells domain2 to use privatekey1 but
domain2 then (mistakenly or otherwise) tells domain3 to re-use
the same key? If private key delegation were common then we'd
have to analyse that, and other, cases. (Which is lots of work,
a thing from which I regularly shy away:-)

S.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Aug 2006 19:54:05 -0700

Stephen Farrell wrote:
>> Isn't it as simple as:  A signer might have practices that permit header
>> fields to have invalid content?
> 
> If so, then that doesn't seem to be dependent on the "SSP DSD" mechanism.
> I've no position on whether that's right or not, but haven't understood what
> the "SSP DSD" mechanism changes.

My statement was intended to be about DKIM, per -base.  Whether publication of
various signing practices changes anything is an entirely separate discussion.

So far, most of the "interesting" suggestions for SSP appear to add complexity
and overhead, with questionable likelihood of benefit, particularly if there is
a simpler approach.

>> DKIM says nothing about key management now.  Why does this need to change,
>> for the particular case of having keys used by someone in another ADMD?
> 
> My earlier mail to Jim may have explained. But saying it again another way
> can help so:
> 
> If we support delegation of signing ("SSP DSD") then I can easily see how to
> do that (by including the delegatee name in some SSP practice statement). If
> however, we don't support delegation of signing, then it may be more likely

DKIM already "supports" delegation of signing.  It comes for free (with respect
to the DKIM specification) by virtue of sub-domain names.

So I think what you mean is the possibility that there is publication of an
explicit delegation list.

Still, I do not see how explicit publication of a delegation list creates any
additional burdens or requirements for documenting how key management is done.
As with the rest of DKIM, internal procedures are internal procedures, even when
"internal" happens to occur between ADMDs.

> that folks make more use of delegation of keys. Once we start down the road
> where delegation of keys is common (or nearly so), then there's an onus on us
> to say how to do that, 

Why?

d/

-- 

  Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 24 Aug 2006 09:04:08 +0200

> How or what will a verifier us to extract policy information
> from this message transaction?
 
> What domain are we protecting in the above available header
> block? company.com? mailinglist.com?

Good example.  The Return-Path is another piece of available
info, but if it matches the PRA listadmin@mailinglist it does
not offer anything new.

The receiver has a fourth piece of info, his address book (any
white or black list).  In a parallel thread about filters Phil
or John just discussed again that a "DKIM PASS" or similar from
unknown strangers is pointless.  With over 84% probability it's
spam like any other mail with or without signature (based on
95% probability unsolicited mail minus 11% misdirected bounces,
I don't recall where I read this some weeks ago).

So for your scenario, if you don't have listadmin@mailinglist
in your address book, and you also don't have president@company
in your address book, then you simply do not care what this is.

Otherwise you know one or both of them, white or black.  And if
it's a white-listed address you're supposed to know their SSP.

If that SSP is "sign everything" the mail is probably spam, and
you should reject it.  Or trash it.  If you intend to bounce it
the details wrt the Return-Path are important.

For an ISP if they happen to know that president@company should
be signed, always, they should reject it, unless they also know
that listadmin@mailinglist is a clueless but otherwise harmless
DKIM-munger.  In that case they should be also "sure" that the
sender really is the sender.

In your scenario there was no DKIM signature, therefore "sure"
means SPF PASS or PRA PASS or something in this direction.  If
there is a forwarding scenario behind the "clueless list" it's
a hopeless case, reject it if you expect a DKIM signature for
president@company.

Frank

---

From: Damon <[email-masked]>
Date: Thu, 24 Aug 2006 10:36:38 -0400

>in your address book, then you simply do not care what this is.

There are 12,434 employees worldwide at my company that are either
sales people or handle some sort of customer service where email is
'directed' to them.
I hope that you are not suggesting that DKIM is pointless unless you
already know the person that is sending to you.

Although... now that I think about it- I agree with you!

In my opinion, I am agreeing with you due to the lack of specific
rules covering who can and cannot sign for me and when/how do I expect
my policy to be enforced.

Regards,
Damon Sauer

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Aug 2006 08:08:10 -0700

> my policy to be enforced.

This is factually incorrect. Dkim-base has very clear and unambiguous rules
about who can sign for you. It would be helpful if you became acquainted 
with
them.

       Mike

---

From: [email-masked] (Wietse Venema)
Date: Thu, 24 Aug 2006 11:09:46 -0400 (EDT)

> my policy to be enforced.

Actually, the problem is that spammers can sign mail.  The mere
presence of a valid DKIM signature, on mail from a total stranger,
doesn't prove that mail isn't spam.

Of course I'm assuming that spammers don't subvert DKIM with zombies
that can send mail with the credentials of people you know.  That
would be against the rules.

	Wietse

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 24 Aug 2006 17:17:52 +0200

Damon wrote:

> I hope that you are not suggesting that DKIM is pointless
> unless you already know the person that is sending to you.

You're right, s/person/domain/ for the D in DKIM.  For Hector's
example @mailinglist could be @yahoogrooups, and you'd know
that these mails should be signed.  And then Hector's example
would be some error (including "errors" by spammers forging the
wrong mailing list), but you'd reject it - if you're sure that
it's no error on your side.

Frank

---

From: Damon <[email-masked]>
Date: Thu, 24 Aug 2006 13:03:43 -0400

> about who can sign for you. It would be helpful if you became acquainted

Really? How so?

Can I say that any email coming from xyz.example.com MUST be signed
and if it isn't, toss it in the bit bucket even if my ISP signs it?
Can I also go on to say, any email coming from abc.example.com may or
may not be signed, but if it is, it needs to be MY signature.

EHLO xyz.example.com
MAIL FROM: <[email-masked]>
RCPT TO: <[email-masked]>
From: <[email-masked]>
and apply a policy that says this mail may or may not be signed.

and also be able to say:

EHLO abc.example.com
MAIL FROM: <[email-masked]>
RCPT TO: <[email-masked]>
From: <[email-masked]>
and apply a policy that says this mail MUST be signed, if it isn't
deliver it to null?

and then say:

EHLO myASP.test.com
MAIL FROM: <[email-masked]>
RCPT TO: <[email-masked]>
From: <[email-masked]>
Reply-To: <[email-masked]>
and apply a policy that says this mail MUST NOT be signed because I am
outsourcing my advertising to someone I may trust but I have no
control over them and I never ever want it confused with my
abc.example.com email which is a huge phishing target?

I don't know... this seems like a typical scenario to me..
If it can't do this, or even come close, then Mike, you have not read
a word I or Hector or others have said. I don't know if this should
surprise me or not. Aren't you the person that is going to be writing
this document?

Regards,
Damon Sauer

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Aug 2006 18:18:51 +0100

> "internal" happens to occur between ADMDs.

I don't think that exchanging public (or even private, yuk) keys between
ADMDs is internal. Nor do I think that encouraging such would be likely 
to sit well when our specs are reviewed later on. (E.g. by secdir, where
I would raise the issue if I drew the document - must check if that can
happen:-)

Where the delagatee supplies a public key to the delegator then its
quite likely that that public key will never get updated. That's a bad
thing.

I'm *not* saying that we have to invent any kind of key management, but
if keys are to be sent between domains (even in a minority of cases),
then we do need to have analysed those cases and shown that there's an
easy way to handle them. IMO, the SSP DSD mechanism is potentially
better from this angle since its ok to exchange signer names once and
never have to change them for other than business reasons. And I find
the argument that SSP DSD means there's little or no need for cross
domain key transport (other than in key records, as per base) to be
fairly convincing, though I don't feel comfortable that I understand
who'll be delegating, when, and to whom.

SSP DSD may of course be worse from other points-of-view, and the
WG may well decide not to do it, or to do it later, or whatever, but
I think a consequence of not including it as a requirement, is that
we increase the amount of work we have to do on key management.

And of course, if there are ways to avoid the key delegation (for
everyone, or almost everyone) using DNS mechanisms, then that's great,
and we're off the hook again. (I haven't totally understood some of
what's been said along those lines to be honest, maybe its a side
effect of the thread being so long.)

Stephen.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Aug 2006 10:13:09 -0700

> may not be signed, but if it is, it needs to be MY signature.

It would be helpful if you didn't conflate too many things at once. I've 
heard
you say on more than one occassion that you believe that DKIM doesn't have
the ability to constrain who signs on your behalf. That's incorrect. 
That constraint
is provided by the requirement that the domain holder place a selector 
into their
DNS for the signer's d= to hold true. The domain holder is thus in 
control who
signs with their domain name.

I'm not commenting on the rest, just that particular aspect.

       Mike

---

From: Damon <[email-masked]>
Date: Thu, 24 Aug 2006 13:38:45 -0400

What do we do when there is no signature and no d= domain to
work with?
This is sort of hazy in my mind.

Regards,
Damon Sauer

---

From: Dave Crocker <[email-masked]>
Date: Thu, 24 Aug 2006 10:49:04 -0700

> I would raise the issue if I drew the document - must check if that can

Yeah, that's what I thought you were going to say.

With respect to the interaction between signer and validator -- and that is what
-base does -- in fact the exchange of private keys is *entirely* an internal
matter for the signer to deal with.

There are lots of inter-organization activities needed for administering many
different Internet protocols, and we do not specify how they are done.  For
example, do we specify how coordination must be done between a domain name
holder and the third party administering their DNS entries?

What makes the specifics of communicating private keys, among consenting
organizations, a matter to count as a *prerequisite* for approving the
interaction between signers and validators?

It seems to be pretty frequent that folks confuse the concept of
internal/external for an Internet service's architecture, with the vagaries of
administrative mix, for portions of the service.  This leads to requiring too
much up-front specification, delaying release of work that is factorable and
entirely useful on its own. (A classic "big system syndrome" problem for
standards and systems designers.)

> quite likely that that public key will never get updated. That's a bad

1. We are not specifying how frequently keys must be changed.

2. We cannot dictate how frequently key are changed.

3. Your assertion that there is, somehow, a particular human/operations impact
when the private key crosses the boundary between partner organizations is
interesting.  Do you have an empirical basis for asserting it?  The observation
is likely to have a significant impact on quite a bit of Internet administration
and the standards for it.

> easy way to handle them.

No we don't.  That is why it is important to recognize that the issue is
*entirely* internal, with respect to the portion of the service that we *are*
designing.

> IMO, the SSP DSD mechanism is potentially

Yes, path registration is a very appealing concept... except for the problems
with it, such as completeness and keeping things current.

If I am understanding the DSD concept, it pertains to publication of an
authorization list.  So I think you are confusing publication of signer agent
name, with the choice between NS delgation to an outsourced signer vs. giving a
private key to them.

Stated differently: I believe that publication of domains authorized to do
signing provides the same functionality as NS delegation of a sub-domain, albeit
with more mechanism, more complexity, and more risk.  But it has nothing to do
with the way private keys are exchanged.

Offhand, I am not seeing why the communication of private keys is all that
different when the signing group is outsourced than when it is exchanged within
an organization.

d/
-- 

  Dave Crocker

---

From: Jon Callas <[email-masked]>
Date: Thu, 24 Aug 2006 11:11:00 -0700

> This is sort of hazy in my mind.

You do anything you want to do. Perhaps more correctly, you do what  
you're doing now. If there's no signature, it's not a DKIM message.

	Jon

---

From: Michael Thomas <[email-masked]>
Date: Thu, 24 Aug 2006 11:27:52 -0700

> This is sort of hazy in my mind.

That's an orthogonal question to your first assertion, and is the very 
subject that
SSP attempts to answer. My only point here is that dkim-base does give you
control over who signs in your domain's name. That's an already solved 
problem
that needn't be revisited by SSP.

       Mike

---

From: Jon Callas <[email-masked]>
Date: Thu, 24 Aug 2006 11:09:12 -0700

> communicate an assurance of the 2822.From address through the use  
> of the dkim-signature i= syntax.  A similar assertion is equally  
> subdomain or otherwise outside the 2822.From domain.  A mechanism  
> for verifying proper use of the 2822.From address could be  
> analogous to steps taken when registering an email-certificate or  
> when subscribing to a mailing-list.
>
> Providers that implements such a mechanism can ensure messages  
> signed for by a specific domain are not forging anyone's email- 
> address.  Allowing DKIM to assert that the 2822.From address is  
> assured valid is clearly beneficial.  This mechanism alone will  
> impact the amount of spam coming through bots, which represents  
> approximately 70% of the overall sources.  An assertion by the DKIM  
> signer made by way of DKIM semantics or a 2822.From policy  
> statement *can* be done.  Knowing which provider properly assures  
> the 2822.From address may require some type of domain assurance  
> council.  : )

Doug, this is also incorrect. The i= "identity" is merely a string  
that is advisory. There is *nothing* that a receiver can deduce about  
it, because it is put there by the signer, who can put anything they  
want.

	Jon

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 24 Aug 2006 14:39:36 -0400

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

> you're doing now. If there's no signature, it's not a DKIM message.

Then this is a MAJOR loophole and it causes harm to verifiers and users,
never mind to domains who did not expect this.   It lowers the payoff for
verifiers to even support DKIM and get this:

        "Spammers now do not need to bother with DKIM.
         A zero cost do nothing technological discovery!"

If we can resolve this, the value of DKIM-BASE has been watered down
tremendously.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 24 Aug 2006 14:15:15 -0400

> *entirely* internal, with respect to the portion of the service that we
> *are* designing.
>
> Yes, path registration is a very appealing concept... except for the
> problems with it, such as completeness and keeping things current.

I don't think anyone is proposing path registration.  If one want path 
registration there are already ways to do that.  In those terms I think DSD 
could be correctly termed origination registration.  

> authorization list.  So I think you are confusing publication of signer
> agent name, with the choice between NS delgation to an outsourced signer
> vs. giving a private key to them.
>
> signing provides the same functionality as NS delegation of a sub-domain,
> albeit with more mechanism, more complexity, and more risk.  But it has
> nothing to do with the way private keys are exchanged.

The only link is that if we don't do a DSD like function, domains that do not 
have access to NS delegation will have to do some kind of key exchange and 
publication.  Probably just public key, so I don't think it's a security 
issue, but it is a complexity/risk issue.

More mechanism yes, and marginally more complexity.  I guess those add to more 
risk, but I think the difference is in the noise.

> different when the signing group is outsourced than when it is exchanged
> within an organization.
>
The risk and complexity is greater.  That doesn't mean it has to be 
standardized, but it should be recognized as a risk.

Scott K

---

From: Damon <[email-masked]>
Date: Thu, 24 Aug 2006 14:49:06 -0400

> that needn't be revisited by SSP.
I don't subscribe to the Word of the Day but orthogonal is indeed what
the question was.
I completely understand that I have control over   whom   may sign for
me. The issue I have is the granularity and selectivity's of the
policy. See my earlier example. This is exactly (minus the fake domain
names) what I am doing right now on a very large scale. So it is a
very "real world" example.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Thu, 24 Aug 2006 14:57:03 -0400

+1

I hired an alarm company to protect my house. They put an alarm on my
front door. I use it thinking it is protecting me and under every
window there is a sign that says "Burglars Enter Here!" and a sign on
the front door that says "The key is under the mat".

 I don't want to have to purchase not one more box or peice of
software that is going to "protect" me by managing all my keys,
relationships, and make reports on the trust levels of everyone else
in order to make this work. I will say the magic word... Please.

Regards,
Damon Sauer

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Aug 2006 11:57:00 -0700

On Aug 24, 2006, at 11:15 AM, Scott Kitterman wrote:

>> If I am understanding the DSD concept, it pertains to publication  
>> of an authorization list.  So I think you are confusing  
>> publication of signer agent name, with the choice between NS  
>> delgation to an outsourced signer vs. giving a private key to them.
>>
>> Stated differently: I believe that publication of domains  
>> authorized to do signing provides the same functionality as NS  
>> delegation of a sub-domain, albeit with more mechanism, more  
>> complexity, and more risk.  But it has nothing to do with the way  
>> private keys are exchanged.
>
> The only link is that if we don't do a DSD like function, domains  
> that do not have access to NS delegation will have to do some kind  
> of key exchange and publication.  Probably just public key, so I  
> don't think it's a security issue, but it is a complexity/risk issue.
>
> More mechanism yes, and marginally more complexity.  I guess those  
> add to more risk, but I think the difference is in the noise.
>
>> Offhand, I am not seeing why the communication of private keys is  
>> all that different when the signing group is outsourced than when  
>> it is exchanged within an organization.
>

Agreed.

A provider that ensures all the 2822.From addresses are valid within  
a specific signing domain will not necessitate _any_ exchanges for  
safe associations to be asserted in a 2822.From policy.  This mode of  
operation allows 2822.From policies to be autonomously administered  
as well.

There are likely many other far reaching benefits obtained when  
assuring 2822.From addresses.  There will always be large outfits  
wanting to relay their email by exchanging keys.  In either case, the  
provider must still be trusted to do the right things.

-Doug

---

From: Jon Callas <[email-masked]>
Date: Thu, 24 Aug 2006 12:23:34 -0700

> Even if my policy states that it must be signed?
>

Whoa, whoa. Hang on. A signing policy is something that exists for  
the *receiver*. If you get a message that has no signature, your  
policy doesn't come into play. The *sender's* policy comes into play.

You are permitted to go out and look at their policy. Heck, you're  
*encouraged* to. But the Internet Police aren't going to remove your  
routes if you're running an old mailer that doesn't speak DKIM.

The sender's policy states what they want you to do if there's no  
signature. If that policy says that their messages must be signed,  
they're saying they want you to black-hole that message (insert small  
hand-wave here in the interest of simplicity).

In the absence of DKIM, you have a responsibility to deliver that  
message. (Again, insert a small handwave here, ignoring spam filters,  
etc.) The combination of DKIM and SSP is a statement that absolves  
you of that responsibility. It's actually states a desire on the part  
of that alleged sender that they want you to treat it as if it were a  
bogus message.

Now, there is no reason why your mail system can't have a setting  
that says to put messages failing SSP in a special maildir. Or to do  
some other thing, too.

	Jon

---

From: Damon <[email-masked]>
Date: Thu, 24 Aug 2006 15:54:34 -0400

> policy doesn't come into play. The *sender's* policy comes into play.

Stop Horse. This is lowest denominator of where we disagree. What's
the point of ~having~ a policy for my signature if the receiver is
just going to make up his own anyway. Can they? Sure they can... and I
can drive my car 140 mph on the freeway if I want. That is not the way
it is going to work. The sender, having gone through all the trouble
of creating a policy is going to expect and in my opinion, should have
every reason to expect, that that policy is going to be honored. I
think we can both agree that the receiver is going to do what they
want anyway, but these people are not free radicals, they are going to
do what your policy says to do and if we don't allow the language that
is going to be used in the policy to make it useful AND encompassing,
then we are going to seriously hamstring this whole thing.

Regards,
Damon Sauer

---

From: Damon <[email-masked]>
Date: Thu, 24 Aug 2006 15:59:08 -0400

And I think after re-reading what you said.. that we are saying the same thing.
So... I am just re-re-reiterating what Jon said.
Color me red.

Regards,
Damon

---

From: Damon <[email-masked]>
Date: Thu, 24 Aug 2006 14:32:31 -0400

On 8/24/06, Jon Callas <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>

Regards,
Damon Sauer

---

From: "Hector Santos" <[email-masked]>
Date: Thu, 24 Aug 2006 16:35:33 -0400

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

> policy doesn't come into play. The *sender's* policy comes into play.

[Horses Pulled Back!  Ducking under flying wrench! :-)]

Isn't DKIM is about the signer, not the sender?  Doesn't this mix 2821 ideas
into the picture?  Ok, then we do have mixed lookup ideas for bare minimum
(not signature) headers lookup rules?

Why can't we look at the 2822.From: domain?

Ignoring the DNS overhead, should a system look at both?

    2822.From:
    2822.Sender:

Why bother with the fall back to Sender? How that help support 2822.From?

> *encouraged* to.

We are?  Whose policy then?  The 2822.From: domain or 2822.Sender: domain?

Jon,

I don't think you really answered Damon's question.  We all know local
policy implementations have the final say.  That's not the issue. Heck,  it
might not even support DKIM at all.

You have a baseline condition of a non-signed message that has to be worked
out.  The point is what value does DKIM offer if DKIM-compliant receivers
are not expected to honor the domain's digital signature expectations.

> In the absence of DKIM, you have a responsibility to deliver
> that message.

No I do not.  In a DKIM world, it raises the bar for a new level of
expectation.

In other words, if expect want verifiers to even bother to invest in DKIM,
to consider the scalability and overhead to do DKIM validation processing,
then need to illustrate a payoff, a reason.

What is the payoff?

> that says to put messages failing SSP in a special maildir. Or to do

Yes that's possible, but that has nothing to do with the fundamental
question of how or where do you extract SSP policy information in a legacy
world of mail transactions where there might not be any signed messages.

---

From: Jon Callas <[email-masked]>
Date: Thu, 24 Aug 2006 13:50:39 -0700

> So... I am just re-re-reiterating what Jon said.

No need to be red. These things are easy to get slightly confused on  
-- cf my confusion in another thread.

	Jon

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Aug 2006 22:33:42 +0100

> Yeah, that's what I thought you were going to say.

Sometimes security-type-opinions are pretty easily predictable, I
agree:-)

I also agree that that doesn't make me right.

> matter for the signer to deal with.

You make an ostensibly reasonable case; one with which I disagree as it
happens.

> interaction between signers and validators?

Well, because private keys are not meant to be sent about willy-nilly,
that's an inherent part of the game. And they're mostly not simple
values that are exchanged like strings either (see pkcs#12 if you
like self-inflicted pain;-). Even public keys are generally transported
in odd formats like certificates etc. that easily generate a lack of
interop. if different folks implement things differently.

I realise that some of the niceties of key management will be over the
top for DKIM, but as someone once said, DKIM has to use signatures since
that's the only mechanism available, so we have to live with some of
the crypto-baggage. (That may even be you I'm misquoting there.)

> standards and systems designers.)

You do have a point, but I don't agree that it applies in this case.

> 1. We are not specifying how frequently keys must be changed.

Correct. But neither do we think its ok to have most keys never
change, right?

> 2. We cannot dictate how frequently key are changed.

Sure. But if change is needed, IMO we need to say how to do it (at
least one way) to get interop. (Note - this doesn't apply to
key records from base where in this respect things are IMO fine
right now.)

> and the standards for it.

Do I have quotable stats? Not offhand. Have I seen this happen in the
real world. Yes. Numerous times. And with messages between banks
involving payments. (In one case a single-DES MACing key was unchanged
for >5 years and was also shared between the bank and >>1 customers.
Major yuk.) I do think this happens for human factors reasons; operators
see the system working fine since when crypto works, its basically
invisible. They easily miss the relationship between staff changes or
retiring equipment and changing those key things that some consultant
setup a few years ago.

> *entirely* internal, with respect to the portion of the service that we *are*

Fair enough. We disagree.

> different when the signing group is outsourced than when it is exchanged within

I think Jon answered the above better than I could, so I won't make it
worse:-)

S.

---

From: Jim Fenton <[email-masked]>
Date: Thu, 24 Aug 2006 17:39:36 -0700

> signing and we haven't really defined signing roles.
You're right, -base deals only with the syntax of signatures and whether
they're valid or not, and does not address roles.  I believe SSP needs
to discuss it to a limited extent (at least whether a given signature is
on behalf of the author or not), and the overview will probably address
this further.
> and in this case, a complex delegation mechanism is worse than none.
SSP DSD would be an additional delegation mechanism which has been
proposed in order to make it easier for some domains to delegate signing
authority.  In addition to other objections I have, if it is not
significantly simpler I question the need for an additional mechanism,
especially in a security context such as this.
> decisions/assumptions at the wrong layer.
-base definitely steered away from discussing the interpretation of the
signature, but DKIM implementations need to make decisions based on
signatures and how they relate to the rest of the message.  My objection
is that the verifier has no choice but to "misinterpret" the signature,
because there isn't enough information there.
> here that cannot happen if no "SSP DSD" mechanism is defined.
I thought I had done that, but I seem to have failed.
> that funny things can happen before signing and the verifier will
I have a list of other concerns, which I'll post separately.  I started
with the security concern because it seemed the most clear-cut objection.
> IMO - it might mean we're not sure what we're protecting?)
I need to think about that.  Mutual non-interference seems like a good
requirement.
> which existing key management scheme(s) to pick for dkim key
Key delegation is already introduced in -base, and we have already
described how the key management works (in DNS, anyway).  SSP DSD isn't
a new key management scheme, but rather a way of authorizing other
domains to sign using the existing scheme.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Aug 2006 17:57:50 -0700

On Aug 24, 2006, at 11:09 AM, Jon Callas wrote:

>> plausible within the 2822.From policy record.  This assurance  
>> could be deferred to the 2822.From policy when the signing domain  
>> is a subdomain or otherwise outside the 2822.From domain.  A  
>> mechanism for verifying proper use of the 2822.From address could  
>> be analogous to steps taken when registering an email-certificate  
>> or when subscribing to a mailing-list.
>>
>> approximately 70% of the overall sources.  An assertion by the  
>> DKIM signer made by way of DKIM semantics or a 2822.From policy  
> that is advisory. There is *nothing* that a receiver can deduce  
> about it, because it is put there by the signer, who can put  
> anything they want.

Agreed.  No algorithm alone can identify good and bad actors.

Good actors establish trust.  Bad actors do not.

When trust is considered an essential prerequisite, then i= syntax  
provides extremely valuable advisory information.

Assume that identity X is trustworthy and uses trustworthy signing  
domains.

Identity X has an email-address of [email-masked].

The 2822.From policy for mr-ex.com also designates big-isp.com as  
offering valid signed 2822.From addresses.

Case 1: mr-ex.com:
  - mr-ex.com is trustworthy.
  - signs all with mr-ex.com.
  - valid identities are noted with i= syntax.

Case 2: big-isp.com:
  - big-isp.com is trustworthy.
  - signs only validated 2822.From with big-isp.com.
  - signs non-validated 2822.From with relay.big-isp.com.
  - signs mailing-lists messages with lists.big-isp.com.
  - valid identities are noted with i= syntax.

A recipient has an MUA that annotates messages when the 2822.From  
address is assured valid AND is found in the address book.

In which case:

  - Messages from [email-masked] signed by mr-ex.com
    use i= syntax to differentiate valid 2822.From addresses.

  - Messages from [email-masked] signed by big-isp.com
    use 2822.From policy in mr-ex.com.

This "advisory" information via either the i= syntax or 2822.From  
policy avoids possible spoofing of a trusted identity.  This approach  
is immune from look-alikes and internationalization exploits.  In  
both cases the signing domain MUST be trusted.  This does not require  
messages from @mr-ex.com not signed by either mr-ex.com or big- 
isp.com to be blocked.  These messages are simply annotated.   
Annotations might be markings or placement into folders.  A critical  
message not annotated as having an assured valid 2822.From address  
AND not from a known trusted sender should be treated with due caution.

This protection depends upon trust in:
  - 2822.From address
  - signing domain
  - signing domain advisory information
  - 2822.From address policy information

Although the mr-ex.com domain would be unsuitable as a designated  
domain, the i= syntax overcomes this limitation.

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Thu, 24 Aug 2006 18:38:26 -0700

On Aug 24, 2006, at 5:39 PM, Jim Fenton wrote:

> In addition to other objections I have, if it is not significantly  
> simpler I question the need for an additional mechanism, especially  
> in a security context such as this.

For any 2822.From address signed with DKIM to be trusted, the  
2822.From address MUST be restricted to accounts where the 2822.From  
being signed is known valid and marked as such using the i= syntax.   
This mechanism MUST exist whether or not any 2822.From policy is  
asserted about this domain.

Assume that a large ISP finds that validating _all_ 2822.From  
addresses for a specific d= signing domain generates revenue as a  
premium service, AND this also reduces support costs related to abuse  
issues.  In addition, this domain can be certified as only signing  
validated addresses.  This certification increases the acceptance  
rate of messages signed by this domain and increases the value of  
their service.  None of these benefits are dependent upon anyone  
designating this domain in their policy.  Such designation will add  
to their stature however and can be monitored. : )

A customer of this service can then independently designate this  
domain in their email-address domain.  This designation process does  
not require the exchange of any keys, key locations, or any special  
handling of their messages.  Just a simple domain name is entered in  
the DNS they control.  Recipients can then identify which trusted  
2822.From address are valid when signed by this domain and are  
designated, without the need of the i= syntax.

The extra effort required would be validating that the holder of the  
account is also the recipient of the address being used.  That effort  
is not much more than what is needed to assure the 2822.From address  
in the first place.  The prerequisite for DKIM security is knowing  
who and what to trust. Being able to convey with DKIM what should be  
trusted is vital for retaining trust and security.

-Doug

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Aug 2006 11:06:22 +0100

Jim,

I look forward to your seeing further problems with this DSD thing.

Meanwhile, I just want to clarify one thing, since I seem to have
confused a number of folks:

> domains to sign using the existing scheme.

I agree. (Well, I can't recall if key delegation is really specified
in base, as opposed to allowed-for by base, but anyway.)

My point is that without the DSD mechanism, key delegation is arguably
much more likely to be used. And if true, that means we have to do more
work analysing key management. With DSD, key delegation is arguably
much less likely to be used, or at least can be more easily avoided, in
which case analysis of key management is less of an issue for us.

Basically, what Jon said in response to Dave, except he said it
better,
S.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 Aug 2006 03:29:12 -0700

> which case analysis of key management is less of an issue for us.

What occurs to me is that I can't keep up with the acronyms, and I suspect
that I'm not alone. Given what Jim writes above, I'm guessing that DSD is
delegated signing domain? Or is it designated signing domain? And is this
what I called "outsourced first party signing" in the requirements draft, or
does this have something to do with DNS delegation?

It seems that if we could all use the same language and acronyms here, we'd
probably help on the talking past each other part.

       Mike

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 25 Aug 2006 07:37:12 -0400

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

> My point is that without the DSD mechanism, key delegation
> is arguably much more likely to be used. And if true, that
> means we have to do more work analysing key management. With
> DSD, key delegation is arguably much less likely to be used,
> or at least can be more easily avoided, in which case
> analysis of key management is less of an issue for us.

I found it interesting this angle you brought up. :-)  Although I understand
you were not advocating either way, I take any plus arguments for SSP DSD.
But I do have to note that I didn't entirely think that it would complicate
key management.  I do see your point though.

I also wish to note that there are two schools here for DSD:

    - DSD list the 3rd party domains only,
    - DSD can also list 1st party domains

The DSAP proposal currently defined the 3PL= tag as a list of 3rd party
domains.  I think this keeps it simple since the main concern is the
uncontrolled, open-ended, unrestricted signing of 3rd party entities.

However, I believe Doug indicated it can help fold or simplify the syntax by
also allowing 1st party domains to be listed as well.  He also suggested
wildcard support, e.g., *.isp.com.

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Aug 2006 12:44:41 +0100

> probably help on the talking past each other part.

Fair point. I don't care what its called and culled the "SSP DSD"
acronym from a posting of Jim's. I could live with either of your
suggested acronym expansions, but the point is that it indicates
the case where an SSP practice lists a number of other domains that
are expected/authorized/allowed/nominated/delegated to sign on
behalf of the domain publishing the practice.

Sorry for being opaque,
S.

---

From: Douglas Otis <[email-masked]>
Date: Fri, 25 Aug 2006 05:25:57 -0700

> behalf of the domain publishing the practice.

Fleshing out a preliminary draft helped establish what terms might be  
needed.  I would like to thank Hector for his contributions to this  
effort.  Both Hector and Scott are invited to collaborate more  
fully.  There does seem to be some general agreements.  Perhaps some  
consensus could be established in the details regarding what is  
needed before entering a domain into either a Designated Signing for  
Domain or Designate Signing for Address list. (DSfD DSfA) or perhaps  
(DSD, or DSA).

This has not been submitted as a draft.  However here are links where  
various terms and required flags are defined.  This was only an  
exercise at building a minimal structure for what a policy record  
might look like.  Please do not consider this to be an attempt to  
upstage ongoing efforts.

http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-dfsp-00.txt
http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-dfsp-00.html

-Doug

---

From: "Hector Santos" <[email-masked]>
Date: Fri, 25 Aug 2006 06:57:20 -0400

----- Original Message ----- 
From: "Michael Thomas" <[email-masked]>
To: "Stephen Farrell" <[email-masked]>

> It seems that if we could all use the same language and 
> acronyms here, we'd probably help on the talking past each 
> other part.

+1

---

From: <[email-masked]>
Date: Thu, 24 Aug 2006 13:54:29 -0400

Policy is to treat the message as unsigned. Remember all receiver policy
is local. If you have an SSP selector that the d= must be signed, local
policy will determine what happens to the message. SSP does not dictate
verifier policy but (in my mind) is informational in nature.
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 Damon
Sent: Thursday, August 24, 2006 1:39 PM
To: Michael Thomas
Cc: Frank Ellermann; [email-masked]
Subject: Re: [ietf-dkim] Re: Delegating responsibility: a make vs.
buydesigndecision

Regards,
Damon Sauer

On 8/24/06, Michael Thomas <[email-masked]> wrote:
> >> This is factually incorrect. Dkim-base has very clear and
unambiguous
> >> rules

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Aug 2006 09:36:03 -0700

> quite likely that that public key will never get updated. That's a bad
But that's not the only form of delegation provided by -base.  It's also
possible for the delegator to publish NS records pointing
_domainkey.delegator.org at name servers managed by the delegatee, and
allowing the delegatee to publish (and update) key records there.  It's
also possible for the delegator to have multiple delegatees, by
publishing NS records for subdomains of the _domainkey domain to
multiple delegatees (which would then use dotted selector names).

The objection to this in favor of Delegated Signing Domains is that
delegators may not have the tools to publish NS records for subdomains.

-Jim

---

From: Dave Crocker <[email-masked]>
Date: Fri, 25 Aug 2006 10:46:00 -0700

Stephen Farrell wrote:
>> With respect to the interaction between signer and validator -- and that is
>> what -base does -- in fact the exchange of private keys is *entirely* an 
>> internal matter for the signer to deal with.
> 

Only ostensibly?

More importantly, I was making a factual assertion about -base.  If you know of
text in it that specifies key management between domain name owner and signers,
please point it out.  All I can see is the brief Section 1.4 that describes lack
of need for a separate key management service.

Almost as an aside, I should note a point that Michael made to me separately,
which is that outsourced signing has a choice for communicating a key:  The
signer can receive the private key from the domain owner, or the signer can
provide the public key to the domain owner.  The latter has the rather large
benefit of not needing to share secret information.

I think that more importantly, for the point of this thread, is that this
demonstrates that key management is its own topic and that the current work, at
most, merely needs to make note of that fact.

> Well, because private keys are not meant to be sent about willy-nilly, that's
> an inherent part of the game. And they're mostly not simple values that are
> exchanged like strings either (see pkcs#12 if you like self-inflicted
> pain;-). Even public keys are generally transported in odd formats like
> certificates etc. that easily generate a lack of interop. if different folks
> implement things differently.

I think the question, here, is whether you are suggesting that we boil the ocean
of extensive issues surrounding every component of an integrated, end-to-end
service? Perhaps that sounds like an over-the-top concern, but I am not seeing
what the boundary to this path is.

You appear to be introducing a brand new issue for the group and appear to be
suggesting that it be handled before -base be released.

I'm probably wrong about one or both of these, but it would be helpful to
clarify it.

   *  What actions are you suggesting?

   *  When are you suggesting they be performed?

   *  What do you see as being required to wait for that to be done?

>> internal/external for an Internet service's architecture, with the vagaries
>> of administrative mix, for portions of the service.  This leads to 
>> requiring too much up-front specification, delaying release of work that is
>>  factorable and entirely useful on its own. (A classic "big system
>> syndrome" problem for standards and systems designers.)
> 

It would be helpful if you explained why.

>>> Where the delagatee supplies a public key to the delegator then its quite
>>> likely that that public key will never get updated. That's a bad thing.
>> 
> Correct. But neither do we think its ok to have most keys never change,
> right?

We do not say anything about such key management.  -base specifies a protocol;
it is not an administrative practices document.  So I am not understanding what
the point of your question, here, is.

> Sure. But if change is needed, IMO we need to say how to do it (at least one
> way) to get interop. 

1. It's not relevant to the signer/validator specification, which is what -base
is.  If it is relevant to SSP, please explain how it affects the current work.

2. In other words, it is a separable issue and all sorts of similar services
work just fine, without having a standard for this particular component.  The
difference between MTA-MTA exchanges and MUA-MSA (or MUA-MDA) seem directly
equivalent.  I do not recall seeing a specification for the way key management
be done, between end-users and the servers they log into. This lack has not
seemed to restrict the ability to have Internet mail operate.

>> 3. Your assertion that there is, somehow, a particular human/operations
>> impact when the private key crosses the boundary between partner 
>> organizations is interesting.  Do you have an empirical basis for asserting
>> it?  The observation is likely to have a significant impact on quite a bit
>> of Internet administration and the standards for it.
> 
> Do I have quotable stats? Not offhand. Have I seen this happen in the real
> world. 

An existence proof does not seem like a strong basis for creating a burden on
the standard where lots of variations are possible.  All sorts of peculiarities
can happen in isolation, but do not warrant changes to a standard for *common*
activity.

>Yes. Numerous times. And with messages between banks involving
> payments. 

What you seem to be doing is making a case for this being a general issue; hence
it is not clear why DKIM somehow has to be required to solve it.

> Fair enough. We disagree.

It is deeper, than that, Stephen.  You are creating a new requirement and it is
for a component of the service that we have not been working on.  You need to
define and justify it.

>>> IMO, the SSP DSD mechanism is potentially better from this angle since
>>> its ok to exchange signer names once and
>> 

I do not know what statements by Jon you are referring to.  I do not see him
explaining how DSD solves key management issues.  Please clarify.

Even more problematic, is that I have not seen how our inventing a mechanism
that burdens receivers with making authorization assessments of delegatees is
somehow better than using DNS sub-domain names.  I have asked folks to explain
this, but have not seen a response yet.

d/
-- 

  Dave Crocker

---

From: John Levine <[email-masked]>
Date: 25 Aug 2006 19:17:21 -0000

>which case analysis of key management is less of an issue for us.

I can see how the analysis would be different, but it's hard to see
why it would be less complex.

With DNS delegation, the name space is a tree, and we understand the
security properties of tree delegation pretty well, warts and all.

With DSD, we now overlay a graph with unknown security properties onto
that tree.  I'd hope we have enough self-discipline to keep it a
two-level graph rather than a Turing complete rats' nest a la SPF, but
recent discussion here is not encouraging.  Even as is I am pretty
sure we have not yet explored all of the grotty things one could do
with existing DNS features and one level of indirection in SSP.  We've
already seen one subtle security bug in a single indirection scheme
that seems to have no solution short of doing severe violence to
dkim-base, and that surely will not be the last.

To me, it just seems nuts to invent a new mechanism with unknown
properties that has not yet been implemented anywhere merely to make
an end run around a few providers who don't currently offer the well
understood delegation scheme that is used for everything else.

R's,
John

---

From: <[email-masked]>
Date: Fri, 25 Aug 2006 15:38:16 -0400

I must be missing much of this argument.
Dkim.bar.com=ISP.com does all of my signing
Dkim.isp.com=publickey_yadayada
That is manageable and not inventing a new technology. I think we need
to avoid not only Touring Complete syndrome but also Tourettes as well.

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

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of John Levine
Sent: Friday, August 25, 2006 3:17 PM
To: [email-masked]
Subject: Re: [ietf-dkim] Delegating responsibility: a make vs. buy
designdecision

R's,
John

---

From: Jim Fenton <[email-masked]>
Date: Fri, 25 Aug 2006 16:14:47 -0700

> which existing key management scheme(s) to pick for dkim key
I finally found the citation I was looking for.

There are two classes of threat regarding key delegation:

1. Threats that exist because of the existence of the key delegation
mechanism.  These might include things like publication of rogue key
records in DNS, by cache poisoning and the like.  I don't think anyone
is proposing that key delegation be eliminated in favor of SSP
delegation, so these threats are unaffected by the prevalence of key
delegation deployment.

2. Threats that relate to the delegation process itself.  These might
include a man-in-the-middle attack in the communication between
delegator and delegatee where the delegatee sends the delegator a public
key to publish in a selector.  This is discussed in the threat analysis,
section 4.1.2, last paragraph.  Since the key delegation process is out
of scope for -base (which really only discusses the signing and
verification process and the format of key records), it's not discussed
there.  But this is a fine topic for the overview document, and I hope
we cover it there.

-Jim

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 26 Aug 2006 00:58:49 +0100

A quibble, a non-quibble and an aside:-)

> delegation, so these threats are unaffected by the prevalence of key

The quibble: the threats are not unaffected if the liklihood changes.
The vulnerability is unaffected, yes, but the threat is affected.
(If, as I do, you consider a threat as being a combination of a
vulnerability, an impact and a probability of occurrence.)

Why its a quibble: because otherwise I agree with you, I've not
heard anyone say SSP delegation totally eliminates the requirement
for other types of delegation.

> there.  But this is a fine topic for the overview document, and I hope

The non-quibble: The overview document will be informational. If we want
to have a standard way to do key, (or SSP DSD), delegation then don't we
need some (perhaps new) normative document? [To be clear: I agree that
base doesn't need this since, as you said, key (and all) delegation is
out of scope for base.]

And as an aside, the threats paragraph you reference is a good one. It
says that one might use signed public keys (e.g. maybe with some other
key in some other key record, or else using certificates) or that one
might use "customary" precautions against the exposure of private keys.
That latter might be taken to mean things like key splitting, which if
adopted (I wouldn't argue for it btw), would require a bit of protocol.
(Saying "send a p12 with <foo> constraints" is way better probably for
that case.) My point is that if we do encourage key delegation then we
may need a bit more normative specification somewhere (but not in base).

S.