[ietf-dkim] [Fwd: I-D ACTION:draft-fenton-dkim-threats-02.txt]

[Jim Fenton]

Douglas Otis wrote:
> On Fri, 2006-01-13 at 17:34 -0800, Jim Fenton wrote:
>   
>> Douglas Otis wrote:
>>
>>     
>>> 1. Introduction
>>> ...
>>> "permitting a signing domain to claim responsibility for the use of a
>>> given email address."
>>>       
>> This wasn't intended to refer to SSP at all. In order to refer to SSP,
>> it would have to be the converse "permitting a sending domain to deny
>> responsibility for unsigned messages".
>>     
>
> The DKIM signature clearly indicates which domain should be held
> accountable for the message, but this statement is about an email-
> address.  It may well become common for providers to sign messages for
> any email-addresses contained within the message.  If the provider
> receives complaints, they disable the offensive account.  In this case,
> the provider would not wish to claim responsibility for any specific
> email-address, perhaps even when the domains match.
>   
It's not clear to me who you mean by the "provider" here.  But it's
entirely up to any signer which messages they want to sign.  Perhaps
they only sign messages that were submitted in an authenticated way. 
Perhaps they only sign messages that come from certain users that have
undergone certain vetting to establish who they really are.
>
>   
>>> 2.3.2.  Within Claimed Originator's Administrative Unit
>>> ...
>>> "DKIM signatures can be used to distinguish between legitimate
>>> externally-originated messages [and attempts to spoof addresses in the
>>> local domain.]"
>>>       
>> Within the claimed originator's AU, publication of SSP isn't needed --
>> the domain knows what it does and doesn't need to incur the risk of
>> having a restrictive SSP inhibit delivery of its messages.
>>     
>
> You mean the policy could be applied internally within the domain?  This
> limits this intra-domain spoofing detection ability to those within this
> domain.  Perhaps you could make a statement for internal policies and
> limited protections versus another for SSP related policies.   
>
>   
I'm saying that SSP need not be the only source of information about the
domain that feeds into decisions about how given messages are handled.

[much omitted here]

> Sorry this is so long, but I think there was some progress made. ;)
>   
I think we are making some progress, although we are getting somewhat
far afield from the threats document on much of this.  It's about time
for me to crank out a revision of the threats document, rather than to
respond on a point-by-point basis.

-Jim