ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)

2005-08-09 16:32:23
Eric,

I think optimization should be put to the side for the moment to consider
what are all the risk for not checking the SSP.  Once all the risk are
addressed programmatically (protocol wise), then of course, optimization
should be considered.  But you have to look at the worst case first. What at
the risk, if any, of not checking the SSP?   How do you know that a original
legitimate 3rd party signer is not some how cracked outside of the DNS
record itself, but the record does say, it doesn't allow 3rd party signing?
Of course, one can argue that a cracker that smart will even bother dealing
with an exclusive domain policy, but the worst cases still needs to be
analyzed.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com



----- Original Message -----
From: "Eric Allman" <eric(_at_)sendmail(_dot_)org>
To: "Scott Kitterman" <ietf-dkim(_at_)kitterman(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Tuesday, August 09, 2005 6:45 PM
Subject: RE: [ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)


I would have thought that validating something that the user
actually sees would have been a primary goal?

Not directly.  The signature has an identity associated with it; that
identity (in the DKIM-Signature header field) is not displayed to the
end user, at least in the current generation of MUAs.  However, we
fully expect (and encourage) verifiers to have some sort of policy
for associating a right to use a visible with the signature identity.
Such association should be driving by the Sender Signing Policy
(SSP).  There is one escape clause: if the signing identity is
identical to the identity in the From header field, the verifier
doesn't have to consult the SSP.  Since we expect this to be the
usual case, it should substantially improve performance.


For example, a domain might be willing to permit a Trusted Third
Party (TTP) to sign on behalf of that domain.  Similarly, large
companies often have several-to-many domains (e.g., movie producers
that buy domain names for each movie); they may do promotional
mailings under a domain name different than the individual vanity
domains.  More prosaically, a sender may wish to assert that they do
(or do not) permit Sender header fields that differ from the From
header field.

So although we /do/ expect that the user will see useful information,
it isn't part of the base spec.  Indeed, in a world with good
reputation systems, it may be that the signing identity will be used
solely for automated filtering --- if the message is signed by a
player known to be honest and upright and a non-spamming,
non-phishing pillar of the community, that may be good enough, and is
actually more friendly for the naive user who just wants their
mailbox to be clean.


_______________________________________________
ietf-dkim mailing list
ietf-dkim(_at_)mipassoc(_dot_)org
http://mipassoc.org/mailman/listinfo/ietf-dkim