I think the question of whether to use the exclude-list or include-list approach comes down to X- headers handling. There's a large proliferation of these headers particularly for security gateway forwarding flows. I suspect the include-list approach will likely ignore X- headers, while exclude-list will by default include signing all of them. The latter will be more sensitive to the rumored MTAs that delete arbitrary X- headers that will need help from the header algebra.
-Wei On Tue, Apr 15, 2025 at 12:22 PM Bron Gondwana <brong= 40fastmailteam....@dmarc.ietf.org> wrote: > Honestly, with the capacity to undo header changes from > dkim2-modification-algebra I would be more inclined to have the spec list > headers which MUST NOT be signed (probably just trace headers), and to list > additional headers to not sign, rather than additional headers to sign. > > I would also mention here than one thing we (or at least I) want to change > between DKIM and this new spec, is that every instance of any signed header > is signed, there's no "oversigning" where you have to list "Subject" twice > in the list to avoid somebody adding a second Subject header which displays > in some systems despite the first one being the one that's checked by the > signature verifier. > > Sure it's wrong, and in a perfect world with perfectly compliant software > that didn't have bugs, that email would be rejected for being > non-spec-correct with its two instances of a single-instance header. But > we don't live in that world, and my design philosophy is to make it hard to > screw up - and if you do, to have the failure be obvious. > > So I'm very interested in a discussion of *"should we have an > exclude-list rather than an include-list of signed headers?"*. I think > that's maybe even the first discussion, followed by* "should said list > have implicit members defined in the spec?"* once we've made a decision > on that first question; and only then if we've decided that question, the > final question of *"what header names should be included in that list?"*. > > Cheers, > > Bron. > > On Mon, Apr 14, 2025, at 15:30, Emil Gustafsson wrote: > > Yes, the reason why each header should be signed should be documented. I > agree with you there. > > I don't understand the purpose of the memory aid comment. > I think it is a good thing if a standard prevents users of the standard > defined from shooting themselves in the foot. Similar to newer versions of > TLS remove insecure ciphers. > If such foot-gun prevention unnecessarily restrict the standard I agree it > should be avoided, but in this case I don't think an implicit header list > is a restriction. If there is such a restriction here that I'm missing, > please elaborate. > /E > > On Mon, Apr 14, 2025 at 9:32 AM Dave Crocker <d...@dcrocker.net> wrote: > > > On 4/14/2025 5:10 PM, Emil Gustafsson wrote: > > rom what I think is the main purpose with a set of defined headers that > have to be signed: Making sure senders don't forget to sign them. > > > Forget? As if a normative requirement in a standard is a memory aid? > > It might help to see some clear, explicit justification for each of the > choices, since it is clear that the goal is quite different from what DKIM > originally intended the header field linkages for. > > Absent such justification, the list is arbitrary and even whimsical. > > d/ > > -- > Dave Crocker > > Brandenburg InternetWorkingbbiw.net > bluesky: @dcrocker.bsky.social > mast: @dcrocker@mastodon.social > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org > > > -- > Bron Gondwana, CEO, Fastmail Pty Ltd > br...@fastmailteam.com > > > _______________________________________________ > Ietf-dkim mailing list -- ietf-dkim@ietf.org > To unsubscribe send an email to ietf-dkim-le...@ietf.org >
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
