EKR wrote:
Hector Santos <hsantos(_at_)santronics(_dot_)com> writes:
In my view, it doesn't matter if its A, B, AB, XYZ or weaker or
stronger. It is about expectations.
if S says I only sign with A, then R should not see signatures with B,
X or Y.
OK, but we're discussing what sorts of policies S should be able to
communicate. In particular, should S be able to say "I sign with
both A and B and any signature you see from me will have both,
not just either."
I understand. I wrote a first draft (DSAP) proposing the concept back in
July/2006:
http://tools.ietf.org/wg/dkim/draft-santos-dkim-dsap-00.txt
section 4.4
4.4. DSAP Tag: a=<hash-algorithm>
The a=<hash-algorithm> tag defines the possible signature hashing
algorithms used by the domain DKIM message signer. The a= tag is NOT
optional.
The current algorithms are defined in DKIM [DKIM-BASE] section 3.3.
o rsa-sha1
o rsa-sha256
Example:
a=rsa-sha1,rsa-sha256;
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 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.
[[anchor17: This verifier lookup concept is best utilize for high-
value domains in 1 to 1 transactions. It would not be practice
Mailing List resigners with large distributions to use this
concept.]]
Seeing failure as unsigned just doesn't cut it for me simply because
there will be MORE failures then success and we will need a way to
deal with that.
It seems to me that you're denying a basic premise of the system.
From base S 4.2:
Verifiers SHOULD ignore failed signatures as though they were not
present in the message. Verifiers SHOULD continue to check
signatures until a signature successfully verifies to the
satisfaction of the verifier. To limit potential denial-of-service
attacks, verifiers MAY limit the total number of signatures they will
attempt to verify.
You are seeming 100% correct. :-)
Its no secret I had seen this as a flawed concept since day UNO and I
strongly believe its the genesis of most of the unsolvable debates here.
This alone is enough to make DKIM unadoptable and unacceptable across
the board in practice. Its like buying a new car knowing you have a
cracked rack and pinion. You shouldn't be surprise there will be
problems with this. :-)
The only redeeming solution is a POLICY based concept that will help put
a definition around inevitable failure. Unhanded Blind Failure is not
going to be tolerated.
Just consider that once you begin to send in a NON-SSP environment, the
default policy is "NEUTRAL."
Whats the point behind DKIM receivers checking X unsigned message vs Y
unsigned message from the same domain? Whats the value between the two?
The concept that there is no value between a REAL unsigned messaged and
a failed signed message in relation to a single domain, to me, is a
flawed concept. To expect receivers to treat these two the same is
asking bit more out of the ordinary logic.
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html