Re: [Ietf-dkim] Headers that should not be automatically oversigned in a DKIM signature?

[Hector Santos <[e-mail]>]

On 2/1/2024 6:38 AM, Alessandro Vesely wrote:
> On Wed 31/Jan/2024 18:34:46 +0100 Hector Santos wrote:
>> If I add this feature to wcDKIM, it can be introduced as:
>>
>> [X] Enable DKIM Replay Protection
>
> That'd be deceptive, as DKIM replay in Dave's sense won't be 
> blocked, while there can be other effects on signature robustness.
>
First, thanks to your and Murray's input.

I need to review Dave's "DKIM Replay" concerns.   Legacy systems have 
many entry points to create, import/export methods, transformation, 
filling missing fields, etc. Overall, I considered the potential 
"Replay" concern was about taking an existing signed message (from a 
purported "trusted signer" ) but MUA display fields, namely, To: and 
Subject: are missing or not signed.  These can potentially be replayed 
with tampered To:, Subject fields and exported.  The multiple 
5322.From headers MUA concern was highlighted many moons ago.  Easily 
Addressed with incoming SMTP filters rejecting multi-From messages.


> A better sentence could be:
>
> [X] Prevent further additions of this field

"This" meaning there is a header selection to monitor?    See below

> Note that some packages allow choices such as
>
> [ ] Sign and oversign only if present in the message
> [ ] Oversign only if already present in the h= list
> [ ] Oversign anyway 

Given how our package offer the signing defaults:

UseRequiredHeadersOnly = 1                       # optional, 1 - use 
RequireHeaders
RequiredHeaders        = 
From:To:Date:Message-Id:Organization:Subject:Received*:List-ID
SkipHeaders            = 
X-*:Authentication-Results:DKIM-Signature:DomainKey-Signature:Return-Path
StripHeaders           =                         # optional, headers 
stripped by resigners

Basically, as the message to be signed headers are read in, each are 
checked again the RequiredHeaders (when enabled).  If missing, the 
header is not signed.  The exception is From: which is always 
signed.   Signed headers are added to the "h=" fields.

So how about this, if I follow this, new namespace fields:

OversignHeader.To = # default blank
OversignHeader.Subject =  # default blank
.
.
OversignHeader.Field-Name=   # future oversign header

This allows an oversign header to be signed if missing.  If correct, 
easily to update the code.

Of course, the MUA is another issue.  What read order should be 
expected for Oversign headers?  Each MUA can be different although I 
would think streamed in data are naturally read sequentially and the 
first display headers found are used in the UI.  Only To: is allowed 
to be a list.


-- 
Hector Santos,
https://santronics.com
https://winserver.com