ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

2006-08-17 11:53:08
Douglas Otis wrote:


On Aug 17, 2006, at 8:44 AM, <Bill(_dot_)Oxley(_at_)cox(_dot_)com> <Bill(_dot_)Oxley(_at_)cox(_dot_)com> wrote:

Big gaping hole, I may assume that isp.com can determine the author/ originator but how to differentiate or not sign a spoof?


To achieve full isolation, sign all sources with a subdomain signature or set the t=s flag at the parent domain key. Make only the signing domain for the sources confirming or constraining the 2822.From address as a designated domain. A structure something like this can be used:

- relay-accounts signed with d=relay.example.com.
- mailing-lists signed with d=lists.example.com.
- user accounts signed with d=example.com.
- example.com is the designated domain for example.com.

There is no gaping hole. Filter relay.example and lists.example from appearing in example.com or set the t=s flag. There can not be any protection in any arrangement unless the 2822.From addresses are constrained or validated prior to use. One method that might be used is to validate each 2822.From per account could be much like that done for a mail-list subscription.

I thought that the entire point of all of this was that it was an easier delegation mechanism. At the point that you have to do all sorts of unnatural acts -- like these -- I think the entire argument unravels. The cure here seems much worse
than the disease.

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