[ietf-dkim] Re: 1368 straw-poll :
hsantos at santronics.com
Mon Feb 26 10:44:29 PST 2007
> Hector Santos <hsantos at santronics.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
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
The current algorithms are defined in DKIM [DKIM-BASE] section 3.3.
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
>> 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.
More information about the ietf-dkim