Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Dave Crocker
DKIM validates the use of an identity.  A validated identity has a number of uses, including as the referential basis for developing a reputation information service.  However identity validation is merely input to the creation of such a service, rather than having any reputation-relat

Re: [ietf-dkim] New DKIM threat analysis draft

2005-10-06 Thread Jim Fenton
Amir Herzberg wrote: Jim Fenton wrote: I have just submitted a new threat analysis of DKIM as an Internet Draft. Hopefully this will form the basis for a meaningful discussion on the utility and effectiveness of DKIM that were voiced at the last BoF. I think it is very good. I have only

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Jim Fenton
Dave Crocker wrote: DKIM is extremely helpful for this scenario because the negative reputation that you have assigned to my identity (errr... domain) can now be reliably and accurately applied. You could not do that so safely in the past. The threat analysis characterizes

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Douglas Otis
On Oct 6, 2005, at 1:40 PM, Dave Crocker wrote: With DKIM you still can not prevent an obnoxious sender who is using a domain that also permits various mail-addresses, unless you want to block all of yahoo.com for example. The only thing DKIM "prevents" is detecting invalid uses of a d

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Dave Crocker
With DKIM you still can not prevent an obnoxious sender who is using a domain that also permits various mail-addresses, unless you want to block all of yahoo.com for example. The only thing DKIM "prevents" is detecting invalid uses of a domain name for a signature. It is well understood that

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Dave Crocker
DKIM is extremely helpful for this scenario because the negative reputation that you have assigned to my identity (errr... domain) can now be reliably and accurately applied. You could not do that so safely in the past. The threat analysis characterizes the bad acts as the spoo

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Jim Fenton
Dave Crocker wrote: The threat analysis characterizes the bad acts as the spoofing of email addresses. My name is Dave Crocker. The domains involved with my email are dcrocker.net, bbiw.net and songbird.com. Hi, Dave. Haven't we met? :-) The domains in the From and Sender and Mai

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Douglas Otis
On Oct 6, 2005, at 12:43 PM, Dave Crocker wrote: The threat analysis characterizes the bad acts as the spoofing of email addresses. I send very obnoxious mail. You do not want to receive my mail. DKIM is extremely helpful for this scenario because the negative reputation that you hav

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Dave Crocker
The threat analysis characterizes the bad acts as the spoofing of email addresses. My name is Dave Crocker. The domains involved with my email are dcrocker.net, bbiw.net and songbird.com. The domains in the From and Sender and MailFrom and Helo and Received fields are all valid and I am

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Douglas Otis
On Oct 6, 2005, at 10:32 AM, Jim Fenton wrote: Douglas Otis wrote: Avoiding repudiation was not heeded within the DKIM draft abstract that explains intent. : ( I really don't understand the above statement. The DKIM abstract makes similar claims and _states_ repudiation is the f

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Douglas Otis
On Oct 6, 2005, at 12:50 AM, Eliot Lear wrote: Doug, Only when the "address" and the signer are the same, would it be possible to safely make assertions of behavior, but then of course extending assertions of behavior to the "address" would not be required. I see little within the thre

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Jim Fenton
Douglas Otis wrote: Avoiding repudiation was not heeded within the DKIM draft abstract that explains intent. : ( I really don't understand the above statement. Clarity is also lacking within the threat document regarding what is meant by the term identity or address. I assume without

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Dave Crocker
It follows that in order to determine responsibility for the sender one first needs to determine responsibility for the domain, and the way that is done with DKIM is via DNS. The source of authority for the sender can then from that point be delegated. Eliot, Thanks for raising the concer

Re: [ietf-dkim] New DKIM threat analysis draft

2005-10-06 Thread Dave Crocker
Folks, I have only one real reservation. In section 6.3, discussing the message replay attack, esp. in 2nd paragraph... It is presented as if DKIM cannot be applied against replay since replay is indistinguishable from acceptable acts e.g. forwarding. This is not necessarily true. A legitimate

Re: [ietf-dkim] New DKIM threat analysis draft

2005-10-06 Thread John Levine
>I have only one real reservation. In section 6.3, discussing the message >replay attack, ... esp. in 2nd paragraph... It is presented as if DKIM >cannot be applied against replay since replay is indistinguishable from >acceptable acts e.g. forwarding. This is not necessarily true. A >legitimat

RE: [ietf-dkim] New DKIM threat analysis draft

2005-10-06 Thread Hallam-Baker, Phillip
> [mailto:[EMAIL PROTECTED] On Behalf Of Amir Herzberg > I have only one real reservation. In section 6.3, discussing > the message replay attack, esp. in 2nd paragraph... It is > presented as if DKIM cannot be applied against replay since > replay is indistinguishable from acceptable acts e.g.

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Eliot Lear
Doug, Only when the "address" and the signer are the same, would it be possible to safely make assertions of behavior, but then of course extending assertions of behavior to the "address" would not be required. I see little within the threat analysis that clarifies this limitation. I am not