ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Features that could be reconsidered as part of the bis process

2009-05-09 22:58:34
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

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