On August 11, 2005 at 13:27, Jim Fenton wrote: > >Why is it not safe? Because a malicious domain can send out messages > >with forged rfc2822.From addresses where the domain portion does not > >have any SSP defined. Therefore, when a DKIM verifier checks the > >SSP for rfc2822.From, the message would not be considered suspicious > >since no SSP record is available. > > > > > But how would they get a valid signature on behalf of the OA? Or are > you saying that one should treat the message differently from an > unsigned message because there is an invalid OA signature present? > > There isn't any reason to apply a signature unless you know it will > verify correctly. Conversely, there isn't any reason to downgrade a > message simply because it has an invalid signature.
The way DKIM is defined, the signature is not bound to the rfc2822.From. I.e. The i= tag can be anything. Therefore, any domain can sign an outgoing message with any From: address in the message header (something phishers will do). To deal with this, DKIM supports SSPs, where the verifier checks the SSP of the rfc2822.From to see what the signing policy is in an attempt to prevent malicious domains using arbitrary rfc2822.From addresses. Now, according to the current SSP draft, if no SSP DNS record is defined for rfc2822.From (or what the draft calls Originator Address), the draft states the following: If the Sender Signing Policy record does not exist, verifier systems MUST assume that some messages from this entity are not signed and the message SHOULD NOT be considered to be Suspicious. Now, in this case, we have a signed message with no SSP defined. Because of this, and past SSP discussion, appears the above statement needs to be revised to avoid a security problem. >From a security perspective, if no DNS SSP record is defined, the safe policy is to treat any _signed_ message as suspicious since it can indicate malicious activity. Not doing so will lead to malicious domains to adopt DKIM since during early stages of DKIM rollout, many domains will not have SSP records defined. There appears to be no real burden to require DNS SSP records to be defined for entities that will have messages signed. For example, if ISP example.com is to implement DKIM signing, along with defining the appropriate DNS records for key data, it can easily define the SSP records. If example.com provides personal address services where users can have addresses with their own domain (e.g. vanity domains, business domains), then SSP records can be defined for the user's domain. If example.com controls the nameservers for the domain, they can define the SSPs directly. If not, then the domain owner must do it if they want to support secure DKIM verification policies. --ewh _______________________________________________ ietf-dkim mailing list [email protected] http://mipassoc.org/mailman/listinfo/ietf-dkim
