On Wed, Jan 31, 2024 at 9:35 AM Hector Santos wrote:
> First time I have come across the term (“oversign”) and it appears to be
> a feature with several products in the market. But checking the RFC, unless
> I missed it, it’s not a RFC defined term. Replay is the term used.
>
You won't find it in any RFC or other formal place. I think I
(accidentally) coined the term when I first added this capability to my
open source work. I needed a short keyword to stick into a configuration
file to turn this on, and that's what came out. We never went back and
added it to the RFC.
To me, the term connotes “redundant signing” beyond what is necessary or
> desired for a particular signing rule.
In a sense it is, but doing so also has a specific preventative side effect
that RFC 6376 describes.
> [X] Enable DKIM Replay Protection
>
> The F1 help will indicate the addition of headers, i.e. To:, Subject:,
> etc. as empty field values are used to enforce the hashing binding of these
> potentially missing headers to the signature. If enabled, then these
> specific headers MUST be included in the list of headers to be signed and
> the headers MUST exist. If not, the headers with empty values will be hash
> bound to the signature.
>
> Is that “Oversigning?”
To protect against this header attack, there's more to it than this.
RFC 6376 says that for each field named in "h=", find the next (bottom-up)
unused instance of that field and feed it to the hash; if there are no more
unused instances, skip it. What this means for "From", for example, is
that if you oversign "from" (by listing it an extra time) on a
normally-formed message, the signer will always hash the one "From" you
have and then skip the extra one. But on verification, if someone has
added an extra "From" field, both of them will get hashed, which means the
signature won't validate because what got hashed at the signer and what got
hashed at the verifier aren't the same.
So more generally, to "oversign" means to include an extra instance of the
field name(s) you want to protect from such insertions by adding one more
instance in "h=" beyond what's in the message at signing time.
It's not true that the header field MUST exist. (You could add that
constraint, but it's not strictly necessary.) I can say "h=banana:..." on
a regular message when that's not a field you expect to be on the message.
If a "Banana" field gets added anywhere, validation will fail, but it
otherwise doesn't interfere with anything.
For the code I wrote, the list of fields to sign and the list of fields to
oversign are separate. The oversign list is just tacked on to the end of
the "h=" before the header hash is finalized. The two lists don't have to
overlap at all (though they usually do).
Finally, I'd be careful about calling this "Replay Protection". It
addresses only one type of replay attack. The sort of replay attack that
caused this group to recharter isn't prevented by oversigning, for example.
-MSK
___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim
