[mail-vet-discuss] Proposed "header.b" tag for DKIM signatures
Murray S. Kucherawy
msk at cloudmark.com
Wed Mar 24 14:02:45 PDT 2010
> -----Original Message-----
> From: Michael Thomas [mailto:mike at mtcc.com]
> Sent: Wednesday, March 24, 2010 1:46 PM
> To: Murray S. Kucherawy
> Cc: mail-vet-discuss at mipassoc.org
> Subject: Re: [mail-vet-discuss] Proposed "header.b" tag for DKIM
> Yeah, it seemed vaguely familiar. The reason I ask is because any IETF
> effort is almost
> by definition a big undertaking, so having a pressing and compelling
> need and a largish
> constituency are usually table stakes. I guess I wonder who that
> constituency is here, and
> whether it's really large enough to get over the ietf energy barrier.
This only requires registration of a new tag in the registries the base auth-results draft created and not a full revision draft or other overhaul work to make it work. This isn't imposing any mandatory new syntax either. It's just creating an optional mechanism that can be used to disambiguate results.
I don't think this will be as big an undertaking as the base draft was, or the other issue will be.
> I just read through the draft and I still don't see the "why" that I'm
> curious about.
> I understand the problem itself, but the why I'm asking about is more
> of "why is
> this an actual problem faced by implementations". Ie, is this something
> that causing
> trouble out in the field? Part of this is my own ignorance about how
> people are actually
> using auth-res, I admit.
I have seen at least one site that signs with a small key (in terms of bits used) and one large key, so it's got two different selectors but all the other signature input parameters are identical. This produces two results. There's no "header.s" so right now you get two results that could be different and no way to tell them apart. The verifier could distill that down to a single result that is the union of the two, but that may not be palatable in all situations (i.e. maybe the receiver cares, but now it can't apply its policy).
There's also at least one DKIM implementation that will not even accept a "dkim=pass" if the signature didn't cover the Subject: header field. And OpenDKIM has various policy features that allow things like "if 'l=' was in use and not enough of the received message was covered, then the signature isn't acceptable regardless of the outcome.
One sender that wants to satisfy multiple DKIM acceptance policies will eventually need to affix multiple signatures with different properties. At the moment there's no way to distinguish those results past the verifier. That's the problem I'm trying to solve. The hints of this are operationally there, but there's not an actual pain point I'm trying to resolve ... yet.
More information about the mail-vet-discuss