On Jan 17, 2007, at 10:39 AM, Scott Kitterman wrote:
On Wed, 17 Jan 2007 10:18:32 -0800 Douglas Otis <[EMAIL PROTECTED]>
wrote:
DKIM's restrictions on linking signatures with a header was premised
upon an expectation that visual examination of headers provided a
means for recognition.
Would you please point me to a reference for this statement?
I recall saying 2822.From should be signed because it's a mandatory
element
of an e-mail message. You seem to remember a different WG
discussion than
I do.
Here is the base draft description of use based upon annotation:
---
Appendix C.
...
The MUA may choose to highlight, accentuate, hide, or otherwise
display any other information that may, in the opinion of the MUA
author, be deemed important to the end user.
---
To better understand the signature selection process, the basis is
the trusted email-address as clearly indicated in the newly added text.
---
4.1
...
Another related example of multiple signers might be forwarding
services, such as those commonly associated with academic alumni
sites.
INFORMATIVE EXAMPLE: A recipient might have an address at
alumni.example.edu, a site that has anti-abuse protection that is
somewhat less effective than the recipient would prefer. Such a
recipient might have [specific authors] whose messages would be
trusted absolutely, but messages from unknown authors which had
passed the forwarder's scrutiny would have only medium trust.
4.2
...
When evaluating a message with multiple signatures, a verifier
SHOULD
evaluate signatures independently and on their own merits. For
example, a verifier that by policy chooses not to accept signatures
with deprecated cryptographic algorithms would consider such
signatures invalid. Verifiers MAY process signatures in any order of
their choice; for example, some verifiers might choose to process
[signatures corresponding to the From field] in the message header
before other signatures. See Section 6.1 for more information about
signature choices.
---
So how is the signature confirmed to correspond with the From header
when ALL signatures must include the From header? The answer is that
the contained email-address MUST be within the domain of the DKIM
signature. Ask yourself why this restriction was imposed. This will
mean that a large email provider's outbound servers may contain
thousands of other domain's private keys! How quickly can all those
domains recover from a breach in this server's security when each
change might require the coordination of more than two entities? Who
signed the message will be what recipients will want to know, but
they will also need to know which Selector was used for each of the
many different domains. What a complete and utterly ridiculous mess!
The far safer alternative would be to allow the DKIM signature to
clearly indicate on who's behalf the signature was being applied,
irrespective of the email-address's domain. This would allow the
verifier to weed through what might be a mess of signatures and
thereby avoid DDoS exploits. When desired, allow the email-address
domain to associate with the signing domain, perhaps by using a SHA1/
base32 tag of the signing domain. (Same overhead as a CNAME.) If a
server becomes compromised, only one private-key is compromised, and
the users of that service can quickly and autonomously respond
without needing to coordinate these changes to restore security. The
security update report will only need to list the one domain that was
compromised and not thousands with all their respective Selectors.
Why should DKIM be allowed to make MTAs such a high level security risk?
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
