[ietf-dkim] Why bother removing features?
steve at wordtothewise.com
Sat Jun 13 12:51:24 PDT 2009
On Jun 13, 2009, at 12:02 PM, Charles Lindsey wrote:
> On Sat, 13 Jun 2009 01:06:59 +0100, Steve Atkins <steve at wordtothewise.com
> > wrote:
>> On Jun 12, 2009, at 6:34 AM, <Bill.Oxley at cox.com>
>> <Bill.Oxley at cox.com>
>>> Okay, I would like to keep what we have, removing pieces is not a
>>> good idea, people don't have to use the tags if they don't want to
>> Implementors have to, for DKIM verifiers at least. Also, even DKIM
>> signers have to either understand the semantics of each and every
>> even if they don't use them, or ignore the spec and use a subset of
>> possible configurations as advised by a third-party deployment
> That is not so. All verifiers have to do is to check whether the
> signature is good, and report accordingly to the Assessor. That
> should include pointing out whether the signature matches the From,
> and also indicating exactly which headers were signed, and reporting
> on any tags seen. For that purposes it is entirely unnecessary to
> understand what most of the tags are supposed to do. Just enough to
> identify how it was signed and whether it was valid.
You might wish it were the case (and I do too, somewhat), but it just
As a concrete example, if you have a public key containing the string
"g=hatstand" and a signature that does not contain the string
"hatstand" then any DKIM verifier must return that the message is
unsigned, by the definition of a DKIM verifier - something that
follows the explicit rules of section 6.1 of RFC 4871 (plus the
implicit rules from other sections).
It cannot do that if it ignores the "g=" or the "i=" flag.
It's easy to construct equivalent proofs for pretty much everything
else (anything other than the PK n= flag, I think).
> And as for assessors, they can take as much or a little notice of
> unusual tags as they see fit. There will care about some tags, and
> simply ignore the ones they don't understand (this in spite of the
> fact that understanding the more unusual tags may enable their
> assessments to be more accurate). But it will take years of
> experience for the assessment community to discover which tags they
> need to take note of. A Best Practice will arise over time, but even
> that may have to change as the Bad Guys find ever more ingenious
> ways to get around the system.
>>> and we MAY have a need for them in the future.
>> We may. Verifiers will need to support them pretty much forever
>> whether we do or not, though. ...
> No, that is just my point. They can probably ignore most of the
> unusual ones, just so long as they include them in their hashes when
A piece of software that ignores any feature that can affect whether a
signature is valid or not is not a DKIM verifier, and will give the
wrong answer in some cases. That might be acceptable to some users
(including me, in some cases) but is not a DKIM verifier as designed
I think your argument boils down to "we don't need to change the spec,
because everyone implementing it can ignore the bits they don't like".
Apart from anything else, that seems as though it would lead to an
awful lot of interoperability failures if some "DKIM verifiers"
consider a message signed while some consider it unsigned.
 6.1 doesn't explain that the verifier must check the v= tag, for
More information about the ietf-dkim