----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
It makes little sense to indicate "sometimes expected." How
would that be useful?
First, lets keep in mind that "sometimes" or the neutral policy is currently
the DKIM-BASE default behavior. It is also the default policy for the
current SSP specs. If no policy is started, equivalent to not having a
policy at all, the behavior is that of a Neutral "It might be sign or not"
behavior.
I agree relaxed provisions, designs and policies will always be the most
problematic. After all, this is what got us here in the first place. :-)
But I would not question the usefulness just yet though.
I can see where a domain may want to "sometimes" sign mail when he thinks he
sending an important message, maybe based on the target or type of
correspondence versus not caring to sign for normal email targets. I may
want to use santronics.com for this mailing list in non-sign mode, but use
it in signed mode for more important direct email correspondence.
However, I do think such a relaxed policy should come with absolutely no
tolerance for failure. If we allow for this type relaxed practice, I would
have trouble dealing with situations where there is a high rate of failures.
In other words, just because you relaxed it, should not imply that since it
is optional, the failure should be ignored.
Anyway, I think the idea is useful, but I personally will not argue against
eliminating the "sometimes" policy. If someone comes up with semantics for
protecting it, maybe the new policy option can be added in the future.
- Highest Signature Hashing method Possible
For less overhead, this information should be included within the key
when an alternative algorithm is required to accompany that signature.
This information should also include the algorithm, service method, and
signature version.
The purpose of this policy attribute is, as described in the DSAP proposal,
The main purpose of the a= tag is to allow domain signers the design
and implementation opportunity to determine the highest strength
possible by a particular target verifier by looking up the DSAP DNS
record for the target recipient domain host. If this query results
with no a= tag information, the default should be rsa-sha1 is the
highest strength possible.
Essentially, this is a negotiation and backward compatibility
concept. It is quite possible earlier pre-standard DKIM
implementations supporting only rsa-sha1 may still exist. The domain
DKIM message signer's desire is to achieve the highest protection
possible. Instead of signing mail with a particular algorithm and
hoping for the best, the signer can predetermine what the receiving
system can handle in terms of hashing strength.
This verifier lookup concept is best utilize for high-value domains
in 1 to 1 transactions. It would not be good practice
with Mailing List resigners with large distributions to use this
concept.
I can see high value systems (those who can afford an advanced
implementations) such as a bank, obtaining email addresses from customers
and lowering failure rates by determining the highest security possible at
the target. We talked about future possible methods beyond SHA256. Maybe
the bank also supports this new method. By looking at the target host
domain SSP record, if any, it can see check for the strong hashing
available.
Also, consider this. A high-value organization investingg in DKIM, might
decide on a new banking policy that all customer email addresses uses for
eBanking are highly secured via DKIM. So they might not just accept any
address from a customer. They might double check it before accepting it and
if deemed not secured enough for their new e-Banking policies, they might
have a joint venture with ESP to provide secured secondary email address for
their customers.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html