On Sun, 2006-08-27 at 08:20 +0200, Frank Ellermann wrote: > Douglas Otis wrote: > > > The problem of look-alikes will only grow worse and is not > > prevented by taking away everyone's freedom. > > Some of them are receivers, we want a common subset of DKIM > functions working similarly for receivers supporting SSP, and > others not supporting SSP. Unilateral delegation is odd.
The word designation was used for a reason. This is not taking anything away the authority of the signing domain, nor is this being done unilaterally from the perspective of the 2822.From address domain. A domain designation does not impact the signature at all. A designated domain may affect the message's annotation or refusal when this permits more aggressive exclusivity assertions. In other words, the 2822.From domain is better protected from fraud when they prefer for economic or convenience considerations to allow someone else to sign their messages. > John's comparison with a Turing-complete path registration > scheme comes to mind: Limited to at most 10 lookups it's in > practice harmless, and limited to CIDRs + mx (without colon) > + a (without colon) + include + all it would be perfect. You should review a draft where this assumption was tested. http://www.ietf.org/internet-drafts/draft-otis-spf-dos-exploit-01.txt Unfortunately, many of the libraries neglect applying even the suggested limitations, and a notable exception where a reduced limit causes unpredictable results for some domains. The straw-man proposal regarding the designation concept is at: http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-dfsp-00.txt You should note that of the three flags, only two will likely ever be used at a point in time. There are two categories of listed domains. a= lists domains where the 2822.From address is assured. d= lists domains where the 2822.From address is not assured. Either of these lists could be infinitely extended by using a single query in the form: <signing-domain>._policy-labels.<from-domain> The latter d= list might be used to to mitigate some of the damage occurring from an assertion of all messages being signed where specific exceptions are desired. > But as soon as folks are forced to "emulate include" (because > the relevant ISP has no policy) things start to get messy as > far as that's possible within the overall limits. "Emulate > include" (SPF) is very near to "unilateral delegation" (SSP). A far safer approach to emulate an SPF mechanism would be to use the same approach as suggested for the designated domain. The query would be: <ehlo-domain>._policy-labels.<mail_from-domain> > [...] > > One might assume this process also applies a block-list of > > known problem addresses as a best practice. > > The dnsbl draft is in limbo at the moment, from an "IETF last > call" POV block-lists might not exist "officially". Maybe we > could adopt the ASRG draft and publish it as DKIM document (?) There is ongoing work to provide this service. > > Sorry, many ISPs may decide to ignore DKIM altogether. > > No problem, a minor point in the security considerations of an > authentication header field RFC. MUAs might need to know what > they get. > > > Perhaps the i= syntax should be revisited or something. > > The i= syntax is apparently fine, unless you want a mandatory > local-part with default postmaster (?). The i= semantics is > less clear. There are alternatives to using i=syntax. This could be some added parameter added to both the key and the signature field making a rather simple assertion: 2822.From address is assured valid. This would provide clearer semantics and overcome i= syntax limitations regarding outside domains. Wietse's concerns with non-matching signatures is solved by treating the a= list as a d= list member and thereby avoid resulting annotations. Two distinct annotations would be the preferred solution, however. Those advocating DKIM should not expect all 2822.From domains will be signed by the same domain, whether from a mailing-list or a large ISP. Allow designations to say "this is really still me". Or perhaps "I use this domain." The use of a d= list is not very ideal, where an a= list offers information valuable to the recipient. This removes the need to ask, "Is this your new signing domain?" The issue of reputation is out of scope, but is getting reviewed as a concern that by adding information, this makes assessing who the actors are more difficult. Only the signer identity can be verified, and only the signer can safely be held accountable. Simple. Just as a provider may allow their users to use their own email-address going through their service, a designated domain represents an exact analogy to this freedom. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
