DomainKeys - Can we get this upgraded to RFC-6376 Specs.

Problem reported by Henry Timmes - 9/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.

Campaign Cleaner - The Ultimate Tool for Optimized, High-Performance Email Campaigns

9 Replies

Reply to Thread

Bruce Barnes Replied

9/5/2015 at 7:25 PM

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

Employee Replied

9/8/2015 at 8:57 AM

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?

Henry Timmes Replied

9/8/2015 at 10:34 AM

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.

Campaign Cleaner - The Ultimate Tool for Optimized, High-Performance Email Campaigns

User Replied

9/8/2015 at 10:47 AM

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.

User Replied

9/8/2015 at 10:54 AM

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.

Henry Timmes Replied

9/8/2015 at 11:11 AM

Fair enough, if taking the purist standpoint on 4870 - but you can allow for this option:

3) Select what headers they want signed

Campaign Cleaner - The Ultimate Tool for Optimized, High-Performance Email Campaigns

Bruce Barnes Replied

9/8/2015 at 11:31 AM

What about the fact that SHA1 depreciates on 1 April, 2016, and will no longer be supported?

Henry Timmes Replied

9/8/2015 at 11:38 AM

Then it just warrants disabling - Domainkeys 4/16

Campaign Cleaner - The Ultimate Tool for Optimized, High-Performance Email Campaigns

User Replied

9/8/2015 at 11:50 AM

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.

Back to Community Threads

Please leave this box unchecked

9 Replies

Reply to Thread

Tags

Related Knowledge Base Articles