[ietf-dkim] Re: 1368 straw-poll :

[Hector Santos]

EKR wrote:
> 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 
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