ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Issue: Section 4.3 Hash method Note

2011-04-25 02:39:26
True, the insightful reader should probably "Get it!"

Rev6 provided a "low security" in "routine" streams reason when sha1 
could be used and rev7 augments a reason not to use sha1 for potential 
lack of verifier support.

Just noting anything "routine" should not have a connotation of low 
security communications.  The only reason I continue to use sha1 is 
because I want maximum verifier support, lower overhead for my system 
and receiver systems balanced against a very low risk, small window of 
message residency opportunity of theoretical SHA1-based unformulated 
DKIM exploits.

If the concern is the potential for lack of verifier support for 
security reasons then probably that is all that needed to be said:

    INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged
    and should always be used whenever possible, using rsa-sha1
    comes with the risk compliant verifiers may not support
    lesser hash strength rsa-sha1 and will treat such messages
    as unsigned.

Whatever.

Murray S. Kucherawy wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Sunday, April 24, 2011 4:39 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: [ietf-dkim] Issue: Section 4.3 Hash method Note

The new rev 07 text has:

   INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged, some
   senders of low-security messages (such as routine newsletters) may
   prefer to use rsa-sha1 because of reduced CPU requirements to
   compute a SHA1 hash.  MTAs with compliant verifierst that do not
   implement rsa-sha1 will treat such messages as unsigned. {DKIM 13}
   In general, rsa-sha256 should always be used whenever possible.

First, there a typo with "verifierst" word,

Typo fixed, thanks.

but I would like to
proposed a modified text:

   INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged
   and in general, should always be used whenever possible, some
   senders may prefer to use rsa-sha1 when balancing higher security
   strength versus reducing CPU-bound signed mail loads. Compliant
   Verifiers may not implement rsa-sha1 and will treat such messages
   as unsigned.

Reasoning: A routine could be anything commonly done and it may
include a high strength requirement as the spec strongly encourages
and recommends should always be used in general.  So IMO, it may help
to be more general by removing the "routine newsletter" example and
the connotation any "routine" mail stream is any less secured
(low-security).

Like your suggestion about 2.3, I fail to see how including an example makes 
a statement less general.  Given that, your suggested paragraph reads exactly 
the same to me as the one we have now.


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html



-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html