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 proposal. > 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 failure. > 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 > is finalized. 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. -- Sincerely Hector Santos http://www.santronics.com _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html