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

From: Scott Kitterman <[email-masked]>
Date: Mon, 21 Aug 2006 19:14:39 -0400

On Mon, 21 Aug 2006 14:55:08 -0700 Michael Thomas <[email-masked]> wrote:
>Scott Kitterman wrote:
>
>>
>>OTOH, it seems to me that it's been said Ad Nauseum.  Where feasible I 
>>agree it's better, but there are operational frictions that will impede 
>>this approach in some cases.
>>  
>>
>What I believe that we've discovered is that this isn't nearly simple as
>some people hoped. Doing as little up front as possible so that you
>can get operational experience is almost certainly better than guessing --
>especially when the guessing wrong is a likely outcome. In this particular
>case, I dooubt there will be harm because receivers will always have an
>incentive to make better decisions (and hence the desire to upgrade).
>
I disagree.  What I think we've discovered that there is no additional 
complexity for signers or authors.  It is, in fact, simpler for signers.

Where the limitation on the sendinding side is imposed is on the 
granularity of the identity for reputation assessment.  Since that's out of 
scope, I don't think we should worry about it to much.

The only place I see added complexity is on the receiving side where there 
may be one additional DNS lookup and some small marginal processing 
requirements.

Modulo the I= discussion from yesterday that I still need some time to sit 
down and think about, I don't think anything of the kind has been shown at 
all.  At most we need some language to avoid dangers that are easily 
avoidable.

Scott K

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

---

From: Jim Fenton <[email-masked]>
Date: Tue, 22 Aug 2006 16:06:08 -0700

> complexity for signers or authors.  It is, in fact, simpler for signers.
With the need to choose the appropriate subdomain depending on which
author-domain submitted the message to the signer, I think the
complexity for signers is now about the same as for key delegation,
assuming that the signer uses the same public key for all of its
customers.  About the only thing that changes from author-domain to
author-domain is the i= address and the d= domain.

-Jim

---

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

On Aug 22, 2006, at 4:06 PM, Jim Fenton wrote:

> Scott Kitterman wrote:
>>
>> I disagree. What I think we've discovered that there is no  
>> additional complexity for signers or authors. It is, in fact,  
>> simpler for signers.
>
> With the need to choose the appropriate subdomain depending on  
> which author-domain submitted the message to the signer, I think  
> the complexity for signers is now about the same as for key  
> delegation, assuming that the signer uses the same public key for  
> all of its customers.  About the only thing that changes from  
> author-domain to author-domain is the i= address and the d= domain.

If an ISP were using the key/location provided to them from various  
customers, there would be an identical process need.  The assigned  
keys however now include a need to acquire these keys rather than  
simply creating them.  In addition, there would be a separate key/ 
domain needed for each customer rather than a common key/domain for  
non-validated 2822.From sources and one for validated 2822.From sources.

-Doug

---

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

> non-validated 2822.From sources and one for validated 2822.From sources.

Couldn't this be a value-add for the ISP?
If all ISP's are like my ISP, they are not adverse to collecting
revenue where ever they may find it.

Regards,
Damon

---

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

On Aug 22, 2006, at 5:05 PM, Damon wrote:

>> If an ISP were using the key/location provided to them from  
>> various customers, there would be an identical process need.  The  
>> assigned keys however now include a need to acquire these keys  
>> rather than simply creating them.  In addition, there would be a  
>> separate key/domain needed for each customer rather than a common  
>> key/domain for non-validated 2822.From sources and one for  
>> validated 2822.From sources.
>

Yes.

A mode where the isp's own domains isolate categories of sources  
should produce several benefits:
  - reduced outbound spam
  - improved message delivery
  - users protected from being a spoof
  - no knowledge of DKIM required of users
  - only d= parameter conveyed to users
  - policy can be autonomously managed by users

The benefits and lack of complex back-office support may justify  
supporting a designated domain mode of operation without added revenues.

> revenue where ever they may find it.

Any DNS delegated mode or key/location exchanges where user specific  
keys are required will likely demand additional revenues to cover the  
administrative costs coordinating with the domain owner and their  
name service provider.  This mode of operation would be used when  
corporate servers are relayed, for example.

For a small account where only a few 2822.From addresses are being  
used, then a designated domain mode of operation is requires fewer  
steps and mechanisms to be supported by the provider.

A provider could support a designate domain mode of operation by  
using _one_ common signing domain for this purpose.
All other sources where the 2822.From addresses are not validated  
would require some other signing domain.

Only when delegated domains are employed would there be a need to  
employ separate domains per account.

-Doug

---

From: [email-masked] (Wietse Venema)
Date: Wed, 23 Aug 2006 08:06:43 -0400 (EDT)

> non-validated 2822.From sources and one for validated 2822.From sources.

There is no need for the signing party to acquire a secret key
from the author party. To delegate signing from example.com
to isp.com, with d=example.com as a first-party signature:

author zone:
    selector.example.com. IN CNAME example.com-selector.isp.com.

signer zone:
    example.com-selector.isp.com. IN TXT keystuff....

The CNAME record is sufficient to delegate both the the private
key and the secret key to the signing party.

	Wietse

---

From: Dave Crocker <[email-masked]>
Date: Wed, 23 Aug 2006 07:58:55 -0700

> to isp.com, with d=example.com as a first-party signature:

There is an administrative choice, here.  One can delegate a zone or delegate a
private key.  The former is more simple, for on-going administrative, but it
leaves less control in the hands of the domain owner.

If the zone is delegated, then the owner does not get to set the TTL for the
signing domain name.  If the owner needs to revoke the sub-domain zone, the TTL
might be quite long, before everyone's cache for it flushes.

d/
-- 

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Aug 2006 09:41:09 -0700

On Aug 23, 2006, at 5:06 AM, Wietse Venema wrote:

> There is no need for the signing party to acquire a secret key from  
> the author party. To delegate signing from example.com to isp.com,  
> with d=example.com as a first-party signature:
>
> author zone:
> The CNAME record is sufficient to delegate both the the private key  
> and the secret key to the signing party.

I did use the term key/location pertaining to each customer.  As a  
minor detail, the "_domainkey" label should be included in your example.

The point was that this requires coordination with the email- 
provider, the domain-owner, and the name-service-provider.  The  
administration of this association can not be done autonomously.   
While the use of a cname might avoid an exchange of private  
information, this information also plays a role in identifying who is  
making the request.  The ISP provider could offer random location  
information in response to the request, and that information would  
then need to serve as the alias in the domain holder's DNS records.   
This can not be done real time, where one typo in the client's alias  
location or in the providers key location will likely create a fair  
number of support calls.

There are few other details needed with this approach as well.  Is  
this key record to be used as a relay?  What is contained within the  
g=, s=, and t= parameters?  What is the TTL?  Are the 2822.From  
addresses being relayed assured valid?  Should messages being signed  
use the i=<full-address> syntax?

Now that you have gone through this effort, you hear of issues  
related to the Active Directory update at the client due to the rare  
use of a cname outside the DNS.  If this technique is done per user,  
then this also magnifies the added overhead with added transactions  
and requisite state guarding against circular referencing. : (

In the end, the email-provider MUST still ensure the account gaining  
access is associated with the correct signing domain.  The  
alternative would avoid negotiating these details.  The alternative  
restriction placed upon the account gaining access would be verified  
2822.From addresses.  If DKIM is to offer significant value to the  
recipient, this 2822.From address restriction mechanism must be  
imposed somewhere along the outbound path anyway or the 2822.From  
address is not assured to be valid.

Delegation by zone/key/location will be more expensive to administer  
and limit the number of 2822.From addresses that are assured valid by  
DKIM.

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 23 Aug 2006 10:41:38 -0700

>leaves less control in the hands of the domain owner.
Just to be absolutely pedantic here, it's better to *enroll* the public 
key vs.
delegating a private key. That said, I agree with what Dave says here.

       Mike