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



_______________________________________________
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

Reply via email to