[mail-vet-discuss] Proposed "header.b" tag for DKIM signatures

Michael Thomas mike at mtcc.com
Wed Mar 24 14:47:39 PDT 2010

On 03/24/2010 02:02 PM, Murray S. Kucherawy wrote:
> 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.

Well, the Null RFC takes, what, about 2 years these days?

>> 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.

Again, I'm not disputing the theoretical problem -- after all as you mention I
pointed it out ages ago :) All I'm really asking is whether this is actually
causing heartburn for people using auth-res. Like, is there some automatons
that depend on auth-res that are puking because of the situations you describe

Mike, just a reality check...

More information about the mail-vet-discuss mailing list