On Tue, 2006-08-29 at 09:27 +0200, Frank Ellermann wrote: > Douglas Otis wrote: > > Some months ago you were firmly in the "crypto timestamp" camp, > what happened ?
DKIM does not assure the signature is unique and lacks any practical revocation mechanism. Tracking and controlling replay activity will be extremely difficult and expensive. DKIM still has value when used to assure the author. At least this should lessen phishing incentives when it becomes less practical. DKIM also provides a reasonable reporting mechanism. > > only when the signature itself indicates the 2822.From > > address has been validated. > > Okay, we can update 5.4 in base if necessary, e.g. add a flag > where that's the case. This could be done as an independent option. > > The factors needed for security are: > > > - a signature assured 2822.From address > > - the DKIM signature associated with the 2822.From address > > (by being within the 2822.From domain or via policy) > > - presences of the valid 2822.From address in the address > > book > > I'd prefer PRA where you say 2822.From, but otherwise ACK. I suspect the reasons for sticking with the From are specifically to avoid the PRA issues and to better tackle the phishing problem? I have labeled the policy DFSP. A DPRAP could be published as well. I am working on solving the issues you raised on the DNS limitations when combining domain names, which should work in regard to other forms of policies as well. I hope to have a version tomorrow. Ahh today. > That's not yet covered in base, how can the MSA say that the 2822-From > is okay ? To incrementally enable this mode of operation, an assertion of the identity validity must apply to any possible domain. A premium service could be provided where the the account holders would access their account page and request to use a validated address. They would verify its receipt, and thereafter for some extended period of time, the address for that account would be marked as valid when using a verified address. See below. > Even where the domains match it's not necessarily okay. Agreed. > The MSA has to know who submits the mail, which PRA can be used by > that authenticated user, and the case PRA != 2822.From has to be > documented, the procedure in that case would be different. The general concept was that the i=<local-part>@<domain> allowed semantics to convey an assertion "this address is valid." i=@<domain> or i=, or no i= at all would be Don't Know. This address can be discovered in any header. It would have been nice had the domain restrictions regarding this assertion did not exist. This would have enabled associations to be made in the DxxxP policy records as a way to easily extend DKIM capabilities. If this mode of use were to become popular and used by default, then this will likely have the biggest impact on spam. These account verification tables could readily detect unusual activity. -Doug _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
