Good starting point list.
Steve Atkins wrote:
Summary of features to consider dropping
DKIM-Signature Header tags
x: Signature expiration
l: Body length count
Removal of these would be a show stopper for me. In fact, overall,
anything that is SECURITY related should be protected from removal
TXT RR tags
t=y: Domain is testing DKIM
+1 Definitely this because that was suggested many moons ago - nothing
can be in perpetual testing and should not be used as an excuse for
t=s: Require that domain in i= and d= are the same
Until POLICY is resolved, I do not suggest removing this.
Other changes to consider
Drop support for SHA1 entirely.
The only technical reason to keep this is that SHA256 is not
guaranteed to be supported on all Windows station which would be a
concern for Window ISVs. However, that was more problematic in the
past because Microsoft made SHA256 and "added value feature" for their
Security layer i.e. you had to update Windows to Vista. But they have
been made aware that SHA256 should be part of the OS security layer
and via service packs have provided in Windows OS.
So its less of an issue today to use SHA256 exclusively. Should SHA1
be dropped? I personally wouldn't vote to remove it.
Discussion of other changes to consider
Drop support for SHA1 entirely. It's beginning to look
cryptographically very dubious, and is being dropped by pretty much
everyone else. Even if the attacks against it don't affect the way
it's used in DKIM it seems unwise to suggest it be used at all. At the
very least it seems a poor "marketing" move to include an algorithm
that's been dropped by most everyone else as insecure before this spec
I don't think this is valid reason for dropping SHA1. First, there is
an overhead penalty using SHA256, second, as indicated above, although
MS did update their OS to include SHA256 support, from a verificattion
standpoint, you are shooting at darts (will the client support the
signature hashing?) and it might be a technical solid idea to have a
common denominator available in the short term for implementations.
Keep in mind that not everyone using OPENSSL, so unless OPENSSL is
made part of the Required DKIM Resources, you can't enforce an method
that simply may not be available on the Windows CLIENT machine.
"Verifiers MUST support rsa-sha256 and MAY support rsa-sha1.
Huh? The verifier will be driven by whatever the signature has and is
capable of supporting. The idea that there might be half-baked DKIM
verifiers is a bad taste for encouraging DKIM signers.
Signers SHOULD sign using rsa-sha256 and SHOULD NOT sign using rsa-
sha1." might provide enough wiggle room to allow existing code time to
migrate away from SHA1.
There should be no MATCHING issue born from any of the this. DKIM
signer and verifiers both must play by the same signing rules.
I understand this is an issue. And it might be ok to stick with
SHA256, but I personally do not see this as a barrier to adoption.
What we should be looking at is WHY, hardly anyone, but only a few
systems are using DKIM. I seriously doubt it is the hashing method or
the expiration or any of the other suggested tags to drop.
The reasons I have not added DKIM into our commercial software is:
- Lack of a visible payoff.
- Lack of policy, what I call the DKIM Domain Ownership Problem
- Cost of implementation (revamping of existing software)
I personally believe we should not be doing BIS with the idea of
REMOVING major parts of it. Today, we live in an integrated world, it
is not the 1980s where each protocol must be isolated fully. No, it
is 2009 and the protocol needs to have integration ideas - WHY is
someone going to bother to sign, why is someone going to verifier, and
quite frankly, we have handicapped the both the signer and verifier
with poor POLICY and DOMAIN Ownership engineering management for the
past 3-4 years.
There is simply no strong incentive to implement DKIM. Streamlining
it ala ADSP isn't going to improve adoption rate. This is a Total,
Big Picture problem.
NOTE WELL: This list operates according to