Subject: RE: [ietf-dkim] Scalability concerns with Designated Signing Domains

From: Arvel Hathcock <[email-masked]>
Date: Wed, 30 Aug 2006 19:52:00 -0500

What a ton of mail to catch up on.

We don't need this kind of complexity in my view.  A delegation mechanism already exists.  I don't see any good reason (so far) for embracing a whole other set of problems trying to reinvent something that already works.

-- 
Arvel 
 
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of william(at)elan.net
Sent: Saturday, August 26, 2006 10:19 AM
To: Jim Fenton
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] Scalability concerns with Designated Signing Domains

I've proposed before that in case of large number of domains SPF-like
macro expansion be allowed in place of actual domain.

On Fri, 25 Aug 2006, Jim Fenton wrote:

> [This is the first of a two messages outlining my concerns about SSP
> Designated Signing Domains.  I'll break each category of concerns into a
> separate thread.]

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

---

From: Douglas Otis <[email-masked]>
Date: Wed, 30 Aug 2006 19:18:34 -0700

On Aug 30, 2006, at 5:52 PM, Arvel Hathcock wrote:

> We don't need this kind of complexity in my view.  A delegation  
> mechanism already exists.  I don't see any good reason (so far) for  
> embracing a whole other set of problems trying to reinvent  
> something that already works.

I agree, nothing as complex as a macro script is desired.  The  
definition of "works" might be in question when attempting to deploy  
this widely to millions of users who all want different  
arrangements.  DNS delegation would be cost prohibitive on a large  
scale when preserving individual freedoms in the use of desired email- 
addresses.

Policy and handling can be simplified in the face of a common  
situation where the signing domain often differs from that of the  
email-address.  One simplification would be to introduce a means to  
indicate whether an email-address is valid irrespective of its  
domain.  Eliminate the presumption an email-address is invalid when  
not within the signing domain.  A verifier can already note this  
difference without being told.  The email-address policy should be  
allowed to associate the signing domain.  The signing domain should  
also be allowed to indicate whether the email-address was verified by  
the account sending the message.  This would allow greatly simplified  
administration while increasing the number of detected forgeries.

  - In the currently expected use, the verifier is
    trusting the signing domain to pick the right
    keys for the address, and that the account
    sending the message is associated with a valid
    address.

  - In the simplified use, the verifier is trusting
    the signing domain to use a common signature,
    and to indicate whether the account gaining
    access has validated the address being used.

The address policy association replaces a need to multiplex keys at  
the MTA, to share private keys, or to delegate thousands of domains.

Which do you think is simpler and safer?

-Doug