ietf-dkim
[Top] [All Lists]

Re: signature construct (was: Re: [ietf-dkim] DKIM BOF -- draft charterand agenda)

2005-10-14 04:58:09
Yes.

I know Earl and I touched base with it in going over the possible error
states, including possible Authentication-Result reporting structure.

http://mipassoc.org/pipermail/ietf-dkim/2005q3/000285.html

I personally saw it as a way to possibly separate what was broken or failed:

    - The DKIM signature policy, and/or
    - The body integrity.

This will certainly help in the area of multiple signings with downlinks,
middle ware systems tampering with mail distribution, if only from one
standpoint: providing a different (less severe?) warning:

So instead of having a generic statement:

   [RED] WARNING: This Message failed DKIM signing

it might help provide a more detail reason

   [YELLOW] WARNING: DKIM Policy ok, but BODY has changed.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com


----- Original Message -----
From: "Stephen Farrell" <stephen(_dot_)farrell(_at_)cs(_dot_)tcd(_dot_)ie>
To: "Earl Hood" <earl(_at_)earlhood(_dot_)com>
Cc: <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Friday, October 14, 2005 7:08 AM
Subject: signature construct (was: Re: [ietf-dkim] DKIM BOF -- draft
charterand agenda)



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