mail-vet-discuss
[Top] [All Lists]

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

2010-03-24 16:03:38
-----Original Message-----
From: Michael Thomas [mailto:mike(_at_)mtcc(_dot_)com]
Sent: Wednesday, March 24, 2010 1:46 PM
To: Murray S. Kucherawy
Cc: mail-vet-discuss(_at_)mipassoc(_dot_)org
Subject: Re: [mail-vet-discuss] Proposed "header.b" tag for DKIM
signatures

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.

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html 

<Prev in Thread] Current Thread [Next in Thread>