[dkim-dev] Choosing sets of headers to sign

Dave Crocker dhc at dcrocker.net
Thu Jan 11 12:58:29 PST 2007


Arvel,

Thanks for responding.


Arvel Hathcock wrote:
>     Now, suppose such a 
> message were displayed based upon a DKIM verification which did not 
> cover the Subject header and that header had been modified for some 
> reason.  This might tend to make the end user believe that the altered 
> Subject text was cryptographically verified and true to the original 

So, one approach is to make sure to sign all fields that are typically displayed 
to users.  (A signature can cover multiple "approaches"; I'm merely trying to 
characterize one of them, from your comment.)


> If you don't want to get into end user details, similar problems could 
> arise in filtering agents if some filter is based upon the accuracy of 
> the Subject text, or omits the filtering of the Subject text altogether, 
> when a valid DKIM signature is present.  This issue needn't be 
> restricted to the Subject header.

This is probably a variant of the MUA display-oriented approach, above:  Sign 
all fields that are expected to be important to a filtering engine.


>  > 1. How are folks deciding what fields to sign?
> 
> In my own case I decided to a) sign all headers (except X type headers) 
> and b) not give my customers a UI to decide which headers to sign and 

This implies that you sign Received fields, and I'll bet you don't.  Perhaps 
your criteria are just a bit more elaborate?


>  > 2. To what extent do we care about different signers choosing
>  > different fields to sign, in terms of how to process a validated
>  > signature?
> 
> I care greatly if the Subject isn't covered for the reason mentioned above.

Does anyone else have thoughts on this?

What would be the minimum set of headers that you would find credible to have 
signed?  And, of course, why?

Do you have any fields, besides Received, that you feel should/must NOT be signed?


And the other line of question is about having different folks signing different 
sets of fields.  Is that variation important?  How?  And how can/should they be 
distinguished by the validator/filter?

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


More information about the dkim-dev mailing list