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

From: Hector Santos <[email-masked]>
Date: Sun, 24 Apr 2011 19:39:14 -0400

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, 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).

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

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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 24 Apr 2011 21:44:42 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hector Santos
> Sent: Sunday, April 24, 2011 4:39 PM
> To: [email-masked]
> Subject: [ietf-dkim] Issue: Section 4.3 Hash method Note
> 
> The new rev 07 text has:
> 
> First, there a typo with "verifierst" word,

Typo fixed, thanks.

> but I would like to

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.

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Apr 2011 03:37:51 -0400

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.

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

---

From: Barry Leiba <[email-masked]>
Date: Mon, 25 Apr 2011 16:39:25 -0400

> My suggestion:
>     and should, in general, be used whenever possible, some
>     senders might prefer to use rsa-sha1 when balancing security
>     strength against performance, complexity, or other needs.
>    Compliant verifiers might not implement rsa-sha1, and they will
>    treat such messages as unsigned.
>
> Barry

I meant to, and then forgot to, sign my message in a way that made it
clear that I'm speaking, here, as a participant only.

Barry, as participant

---

From: Barry Leiba <[email-masked]>
Date: Mon, 25 Apr 2011 16:57:16 -0400

Dave further tweaks:
>      INFORMATIVE NOTE: Although use of rsa-sha256 is strongly encouraged,
>      some senders might prefer to use rsa-sha1 when balancing security
>      strength against performance, complexity, or other needs.  However,
>      compliant verifiers might not implement rsa-sha1; they will treat
>      such messages as unsigned.

WFM.

Barry, as participant

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 25 Apr 2011 13:55:13 -0700

On 4/25/2011 1:37 PM, Barry Leiba wrote:
> My suggestion: INFORMATIVE NOTE: Although rsa-sha256 is strongly encouraged
> and should, in general, be used whenever possible, some senders might prefer
> to use rsa-sha1 when balancing security strength against performance,
> complexity, or other needs. Compliant verifiers might not implement rsa-sha1,
> and they will treat such messages as unsigned.

'should' is another protected word. Worse, the tone of the sentence using it
really is prescriptive and the 'should' is essentially repeating a normative
statement provided elsewere -- essentially creating a redundant specification.

So...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Mon, 25 Apr 2011 17:15:41 -0400

> Barry replied:
>> strength against performance, complexity, or other needs. �However,

+1

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 25 Apr 2011 13:45:21 -0700

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
> Sent: Monday, April 25, 2011 1:37 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Re: [ietf-dkim] Issue: Section 4.3 Hash method Note
> 
> Actually, with one important correction (below), I like Hector's text
> better.  I do think the attempt at a concrete example is a red
> herring, and I prefer more abstract statement.  For that matter, I
> even think the "CPU-bound" part is too specific, so I'll offer a small
> tweak.
> 
> The important correction is to change "may", which could be
> interpreted as RFC 2119 language, to something else ("might", say).
> That's particularly significant in "verifiers may not implement",
> which might be incorrectly read as "verifiers MUST NOT implement", or
> some such.  It's easy to avoid that.
> 
> My suggestion:

You're right, I'd missed the "may" use, and "might" is better.

The tracker's still down, but I'll reopen that issue (#13) for the next version and cite this suggested text.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 25 Apr 2011 16:37:24 -0400

> 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.

My suggestion:

Barry

---

From: Michael Thomas <[email-masked]>
Date: Mon, 25 Apr 2011 16:11:34 -0700

>>       such messages as unsigned.

This seems rather extreme. Last thing I've heard is that
SHA1 has been shown to have a weakness, but it hasn't
been broken. Given that we're using unsecured DNS to
deliver public keys, this seems a like a hysterical
overreaction.

Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 26 Apr 2011 00:19:10 -0400

>  such messages as unsigned.

While I agree with your version, if there is anything else to 
reconsider it would be the last sentence:

     However, compliant verifiers might not implement rsa-sha1;
     they will treat such messages as unsigned.

If the intent is to encourage removing/adding software support for 
rsa-sha1, then the text is good.  However, if that is not your intent, 
changing it to:

     However, compliant verifiers who have not enabled rsa-sha1
     will treat such messages as unsigned.

may better reflect all paths an implementator may take with this note.

Reasoning:

The "might not implement" text implies the idea updated verifiers may 
decide to completely pull SHA1 support from existing code and future 
new verifiers deciding to not bother to add and implement sha1 support.

IMO, this is a lesser practical path for new and updated systems 
because new implementators not adding sha1 support will be cutting 
itself off from the total market potential and any current 
implementators pulling sha1 support or current sha1 mail streams will 
break down when the receiver software are updated to RFC4871bis level.

It would be more practical for implementators to consider the least 
surprise, the least code change expensive route by just adding a 
single logical condition for a "Just in Case" global failsafe turn off 
switch:

   if (Signature.UsingSHA1 && verifier.opts.FailSHA1)
       return DKIM_SIGNATURE_INVALID;

IMO, the new suggested text should cover all the RFC4871bis paths an 
implementator may take with this particular note:

   - Updated systems pulling sha1 support,
   - New systems never adding sha1 support, or
   - All systems adding a failsafe switch to disable sha1.

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 26 Apr 2011 12:07:53 +0200

>      they will treat such messages as unsigned.

That seems to say rsa-sha1 signatures will be ignored independently of
a verifier's capabilities.  Taking into account Mike's note, I'd limit
such behavior to verifiers that (for some reason) cannot do otherwise.

> may better reflect all paths an implementator may take with this note.

+1, or even better with Murray's original wording

       However, compliant verifiers who do not implement rsa-sha1