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: [email protected] [mailto:[email protected]]
>> On Behalf Of Hector Santos
>> Sent: Sunday, April 24, 2011 4:39 PM
>> To: [email protected]
>> 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
