ietf-dkim
[Top] [All Lists]

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

2006-01-15 20:27:25
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

_______________________________________________
ietf-dkim mailing list
http://dkim.org