[Hector, apparently you have unsubscribed, which is unfortunate. I'm
not sure this will be of interest to you, but it may be to others on the
list.]
Hector Santos wrote:
Threats:
- Adversary gains unauthorized access to domain private key
- Internal thief (black market) of domain private key
This is seems to be along the lines of Section 9.2, though that
section seems to talk mostly about user keys being compromised.
Perhaps that section can be broken into two subsections: one on
malware and user keys, and a second with an emphasis on protecting
private keys under the control of sysadmins.
I agree. A side note would be that private keys will mostly likely be
automated (coupled with some change frequency). So this automation has to be
protected.
Section 9.2 indeed does focus on compromise of user keys, as a way of
pointing out the additional potential threats associated with MUA-based
signing. But you're correct, there should be more discussion about the
other ways in which keys might be compromised.
- Adversary compromises MUA DKIM signers
See above.
The difference between the two is the entry points and the protected
resources. One addresses the server-side, one address the client-side. From
a business standpoint, I think we are talking about key management
responsibility. From a design standpoint, rethorically, do we really want
the MUA to be signing? Why not just move the responsibility to the MSA or
outgoing MTA? One less threat with user level exploits.
To the extent that MUAs use SMTP to send messages, I can't think of a
general way to prohibit MUA signing, so it might be best to describe the
associated issues.
Side note: I can see new LEGAL conflicts here. "A email service removing a
DKIM signature does causing tort or harm to reputation of domain."
For that matter, an email service modifying a message in a way that
invalidates the signature does that too.
- Signers who do not honor OA SSP
I don't understand how this is an attack on DKIM.
Correction:
- Signers and verifiers who do not honor OA SSP
If a message is signed as a EXCLUSIVE policy, then no additional 3rd party
resigning must take place. Conversely, a verifier should raise a red-flag
when it sees a conflicting signing. i.e., 3rd party signed message when the
OA domain policy indicates no 3rd party signing allowed.
Hence, signers and verifiers need to double check policies. The current
protocol has an optimization feature where it only checks for the OA SSP
policy under certain conditions.
I think this optimization is premature. The worst scenarios are still
possible when this optimization is enabled.
I don't see the harm in extra signatures. If there is a valid OA
signature on a message, what attack is facilitated by the application of
an unnecessary third-party signature?
-Jim
_______________________________________________
ietf-dkim mailing list
http://dkim.org