DomainKeys - Can we get this upgraded to RFC-6376 Specs.
Problem reported by Henry Timmes - September 5, 2015 at 6:00 PM
Submitted
Currently SmarterMail doesn't allow you to specify a Hash Algorithm for "Domain Keys Signing" and default it's to SHA1 - You should allow us to choose SHA256
 
https://tools.ietf.org/html/rfc6376#section-3.3
 
DKIM supports multiple digital signature algorithms.  Two algorithms
   are defined by this specification at this time: rsa-sha1 and rsa-
   sha256.  Signers MUST implement and SHOULD sign using rsa-sha256.
   Verifiers MUST implement both rsa-sha1 and rsa-sha256.
 
In addition, DomainKeys gives us the option to set a single canonicalization method "Simple" or "nofws". 
 
"nofws" was in the old standard and has been removed. We should be able to set both the Body and Header Separately as we do for DKIM Signing.
 
https://tools.ietf.org/html/rfc6376#section-3.5
c= Message canonicalization (plain-text; OPTIONAL, default is
      "simple/simple").  This tag informs the Verifier of the type of
      canonicalization used to prepare the message for signing.  It
      consists of two names separated by a "slash" (%d47) character,
      corresponding to the header and body canonicalization algorithms,
      respectively.  These algorithms are described in Section 3.4.  If
      only one algorithm is named, that algorithm is used for the header
      and "simple" is used for the body.  For example, "c=relaxed" is
      treated the same as "c=relaxed/simple".
I also thing you should give us the ability to set the "Headers" that get signed, just as you do for DKIM and it shouldn't be pre-setted. 
 
I seen a few instances where people test out Smartermail, because I use Smartermail, then when they notice these issues, they switch to a different mail server. It will be nice if we can get this changed, I want as many people using Smartermail as possible. 
 
 
www.unlocktheinbox.com

9 Replies

Reply to Thread
0
Bruce Barnes Replied
Second the motion on this. Since the code is already in place, for DKIM, it should be easily replicated to DomainKeys. The SHA256 option is particularly important, considering SHA1 depreciates early in 2016.
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Robert Emmett Replied
Employee Post
Henry, thank you for bringing this topic up.  DomainKeys (RFC4870) and DKIM (RFC6376) signing are two different specs.  DKIM effectively obsoleted DomainKeys starting in RFC4871.  The RFC you refer to throughout your posting is specifically for DKIM.
 
We have been speaking as a development team to completely remove DomainKeys from within SmarterMail and leaving only DKIM for mail signing.  Henry / Bruce, what are you thoughts about us completely removing DomainKey signing from SmarterMail?
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Henry Timmes Replied
Robert, 
 
     That's a call SmarterMail is going to have to make, according to http://mailchimp.com/about/authentication/  there are 6 major US/CANADA companies that still verify base off "DomainKeys" - I don't know how accurate or dated this information is. 
 
     I also did a quick search in google and it seems that some of the larger email marketing companies - still sign with "DomainKeys" in addition to "DKIM".  Their businesses are entirely dependent of email deliver-ability, so they must have stats that warrant signing with both. 
 
I personally will like to see: 
 
DomainKeys to be implemented like you implemented DKIM (So It can be configured properly) 
 
      1) Sha256
      2) Select Relexad/Simple (for head/body) 
      3) Select what headers they want signed
 
 
You can remove it all together - But as a mail owner we already have the option to enable/disable it. 
www.unlocktheinbox.com
0
User Replied
As far as I am aware, the only DomainKeys specification is RFC 4870. The RFC that obsoletes that is the DKIM RFC that you reference. I don't think we can take aspects of DKIM and implement then in DomainKeys implementation. The DomainKeys RFC only ever references SHA1. To update it using RFC 6376 would be to make it be DKIM, which we already have of course.

At this point I believe people should be using DKIM and not DomainKeys, but I'm not sure if the timing is right to remove that entirely yet. That just something we need to look into.
0
User Replied
When we say we are considering removing DomainKeys, we mean the signing portion of it. We could and likely would keep the verification part in there.

As far as making the changes you are recommending, I am fairly certain that would break DomainKey verification since the RFC that is specifically for DomainKeys doesn't mention supporting those options.
0
Henry Timmes Replied
Fair enough, if taking the purist standpoint on 4870 - but you can allow for this option:

3) Select what headers they want signed
www.unlocktheinbox.com
0
Bruce Barnes Replied
What about the fact that SHA1 depreciates on 1 April, 2016, and will no longer be supported?
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Henry Timmes Replied
Then it just warrants disabling - Domainkeys 4/16
www.unlocktheinbox.com
0
User Replied
Yes, we will likely remove the signing portion of it for SmarterMail 15. In that case I don't think it makes much sense to update it in version 14 to sign a specified list of headers.

Reply to Thread