[ietf-dkim] Re: signature construct

[Jim Fenton]

Very early in the design process for IIM we considered something like 
this (I think well before we published the IIM -00 draft).  The idea was 
that we could make a provisional decision based on the message header 
information alone, and then just confirm that the body hash was correct.

We dropped the idea because it is a little more complex and, apart from 
the obvious diagnostic benefit (which we could get other ways), it 
wasn't a compelling-enough optimization to be worth the trouble.  Once 
you're into the DATA stage of the message transmission, you don't have 
another opportunity to send feedback to the sending MTA until you have 
received the entire message body, and in any case I didn't expect IIM to 
be used to reject messages out of hand.  But I'm willing to revisit that 
decision, especially since there is now stronger sending policy that 
might make outright rejection a possibility in some cases.

-Jim

Stephen Farrell wrote:

>
> Folks - was Earl's idea considered before? I think there's
> the basis for a good thing there - something that allows
> an intermediary to check the math of the signature but
> without processing the entire (potentially huge) message.
>
> However, this is something to think about later since I guess
> its really an optimisation (albeit perhaps a v. nice one)
> though it does also help when mangling happened, even if at
> the expense of a little more complexity in terms of the
> data structures we require.
>
> Stephen.
>
> PS: Just so's I can reconstruct it for myself later, the construct
> might end up something like:
>   body-hash = Hash1(nonce, body)
>   sig-bits  = Private-key(Hash2(nonce,header-stuff, body-hash))
> The headers would then have to contain the nonce, sig-bits and body
> hash (as well as our other stuff). I guess in principle hash1 and
> hash2 could differ, e.g. in terms of c14n, but that might start
> getting over complex.
>
> Earl Hood wrote:
>
>> Another example: The data "protected" is represented as a hash value
>> parameter.  The signature is only of the DKIM-Signature field, nothing
>> else.  This allows quicker failures on cryptographic signature check
>> since the whole mail message is no longer required.  Only if the
>> cryptographic signature check passes does the complete message need
>> to be processed to check the data hash value.
>>
>> Also, a DKIM-Signature field can still be partially validated even
>> if the message data is mutated to invalidate the data hash.  DKIM,
>> as it is defined now, cannot do this.  This clearly allows us to know
>> when a domain puts in a valid signature during the transmission life
>> of a message, even if message mutation causes full validation to fail
>> for the signature (i.e. the data hash comparision fails).
>>
>> There are also logging and audit advantages of isolating the
>> cryptographic signature to just the DKIM-Signature field.
>>
>> --ewh
>>
>>
>
> _______________________________________________
> ietf-dkim mailing list
> http://dkim.org
>