[ietf-dkim] forward to friend, was besides mailing lists...

[Douglas Otis]

On 5/5/10 5:22 PM, Murray S. Kucherawy wrote:
>>   On Behalf Of Douglas Otis Sent: Wednesday, May 05, 2010 8:59 AM
>>
>> It is clear that sharing DKIM keys will not scale, determining spoofed
>> mailing-list by ISPs will not scale, publishing SPF address lists will
>> not scale.  However, since the publishing of hash labels can be
>> automated or delegated, why would this be something that does not
>> scale?
>>      
> There are two points here that don't scale to me:
>
> 1) I don't think putting a burden on the users to register every list to which they might want to subscribe, or become subscribed, is scalable.
Most lists today require a subscription process.  An exchange upon 
acceptance of a subscription could trigger the publication of TPA 
records for service domains.
> They will forget, or do it wrong, or lists will relocate to different domains, or a host of other scenarios, and then mail will start bouncing and complaints will fly.
>    
A list changing its domain will cause similar problems.  Has anyone 
described lists changing their domain as causing a scaling issue?  A 
mailing-list changing its domain in conjunction with use of ADSP "all" 
would cause users to receiving similar feedback and to raise similar 
complaints.   Since third-party authorization eliminates a need for 
policy exceptions, use of  ADSP "discardable" could be deprecated as a 
bad practice that causes lost messages.
> 2) I don't think that a large organization with security-focused operations people will think kindly of the idea of user-generated data making its way into the DNS, whether that's an automated process or not.  That doesn't even touch on the issue that user-generated data is being used to publish some kind of authorization of the use of that domain by others.
>    
Unlike SPF authorizations that would include any message handled by a 
server, a DKIM third-party authorization is limited to the specific 
service domain.  And unlike SPF authorizations, the service domain can 
be differentiated from servers of the Author Domain and annotated as 
such.  The authorization of the third-party service only requests 
specific exceptions when applying restrictive ADSP policies.

By not leaving ADSP exceptions open to the discretion of any number of 
receiving domains,  a security focused operation retains its ability to 
take effective actions when a problem is detected.  In addition, unlike 
SPF authorizations, an automated audit of the third-party message 
handling should provide reasonable assurances against spoofing.  No such 
assurance is possible with SPF authorizations.

There was never a suggestion that user generated data be published in 
DNS, nor that automation exclude reputation checks or auditing 
procedures.  It should be clear that being able to request specific ADSP 
exceptions for third-party services only _enhances_ security when 
governed by those having the greatest interest in protecting recipient 
trust.

-Doug