On Wed, Jan 31, 2024 at 9:35 AM Hector Santos <hsantos= 40isdg....@dmarc.ietf.org> 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
