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