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
_______________________________________________
ietf-dkim mailing list
http://dkim.org