Subject: Re: [TLS] SHA-1 vs. FNV-1

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Sun, 9 May 2010 17:19:44 -0400

Mike is correct. As the risk of repeating myself: our current practice of using SHA-1 is dying just like the previous practice of using MD5 (and MD4 before it) is dead. So justifying continuous use of SHA-1 is improper: for security purposes it is broken, and for non-security purposes it's rather slow. The initial drive to move to SHA-1 was based solely on security needs and reasons - which do not apply any more. 

Need more be said?

Regards,
Uri

----- Original Message -----
From: [email-masked] <[email-masked]>
To: Eric Rescorla <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Sun May 09 17:07:18 2010
Subject: Re: [TLS] SHA-1 vs. FNV-1

Eric Rescorla wrote:
> 
> Really, given that the security analysis for why you don't need a secure
> hash needs to be written in any case, and that we're NOT using MD5
> but rather SHA-1, I don't see that the argument you're presenting
> for deviating from our standard SHA-1 using practice is compelling at
> all.

Won't there be a push to get rid of SHA-1 from protocols just as there
is for MD5 today?  It seems prudent NOT to use SHA-1 precisely for the
same reason we are not using MD5.

Mike
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Marsh Ray <[email-masked]>
Date: Mon, 10 May 2010 11:35:15 -0500

On 5/9/2010 4:19 PM, Blumenthal, Uri - 0668 - MITLL wrote:
> our current
> practice of using SHA-1 is dying just like the previous practice of
> using MD5 (and MD4 before it) is dead. So justifying continuous use
> of SHA-1 is improper: for security purposes it is broken, and for
> non-security purposes it's rather slow.

Well said. That is my opinion, too.

To put it another way: Any argument that could be made in favor of using
SHA-1 could be made in favor of MD5 (or even MD4). In fact, MD5 would be
superior. It's also "in everybody's stack already" right? (Ignoring
those for the moment those who will implement only TLS 1.2 and forward.)
Plus, MD5 is more efficient. So anybody insisting on SHA-1 should
justify the extra CPU usage over MD5, no?

Let's not forget where this started:

Additional protocol elements for dynamically negotiating among a
extensible set of cryptographic hash functions for use where a
cryptographic hash function was not needed anyway. Vendors would be
expected to support some perpetual subset of them or risk
interoperability problems (probably everyone would just end up using
that one everywhere anyway). Servers might have to track multiple hash
values for the same resource. Another set of parameters for attackers to
manipulate imperfect implementations with. Additional explanation when a
security review legitimately questions the use of deprecated crypto
algorithms.

After:

"Use this 5 line multiply-add loop: [sample code]"

- Marsh

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 May 2010 09:41:25 -0700

> justify the extra CPU usage over MD5, no?

No, that's not true. Again, SHA-1 is simply the default hash algorithm people
use at this point. Other than that, MD5 would be fine, yes.

As for "insisting", I really don't know what you mean. I'm not "insisting"
on SHA-1 any more than Stefan is "insisting" on FNV-1. This is an undecided
question in the WG and I'm stating my opinion.

> manipulate imperfect implementations with.

I have no brief for those elements. I'm happy to simply mandate SHA-1.

> Additional explanation when a

As I noted previously, that exact explanation will need to be present
to justify the use of a non-cryptographic hash.

-Ekr

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Mon, 10 May 2010 12:55:47 -0400

> to justify the use of a non-cryptographic hash.

I see absolutely no need to justify use of non-crypto algorithms for
non-crypto purposes. "It's faster" would be all I'd care to say on the
subject.

In fact it's the other way around: those who prefer to use crypto-strength
algorithms for non-crypto purposes - should justify the extra burden it
would cause for applications. This is complicated by another simple fact -
SHA-1 is not an algorithm of "crypto-strength" any more anyway.

P.S. Why would anyone want to keep SHA-1 at this time is beyond me.
-- 
Regards,
Uri

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 May 2010 18:57:37 +0200

Eric Rescorla <[email-masked]> writes:

> Again, SHA-1 is simply the default hash algorithm people use at this
> point.

Define "people"?  As far as I can tell, SHA-256 is the "default hash
algorithm" many people use, and SHA-1 and MD5 is used only when
backwards compatibility is required (which, admittedly, is very often).

Not long ago, MD4 was included in the set of hash functions that had to
be supported for backwards compatibility.  Fortunately, I rarely find
myself needing a MD4 implementation today.  (Although I happened to need
one for a project last week, and couldn't assume the system crypto
libraries provided it because MD4 is often disabled...  I predict that
MD5 and SHA1 will go the same way eventually.)

/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 May 2010 09:58:18 -0700

I fear I'm repeating myself, but...

> non-crypto purposes. "It's faster" would be all I'd care to say on the

The requirement is to explain why this is a non-crypto purpose. That's
where the analysis comes in.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 May 2010 10:00:14 -0700

On Mon, May 10, 2010 at 9:57 AM, Simon Josefsson <[email-masked]> wrote:
> Define "people"?

Uh, the hash algorithm that's by far in the widest use? Seriously, is
there some question about this in a world where we only added support
for SHA-256 to TLS 1.2 about a  year ago?

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 10 May 2010 19:02:17 +0200

> where the analysis comes in.

This is in the security considerations section.
Do we need more?

/Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 May 2010 10:03:50 -0700

> This is in the security considerations section.

In that case, I fail to see how the argument that SHA-1 requires some whole
other layer of explanation has any force at all.

-ekr

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Mon, 10 May 2010 13:09:00 -0400

> where the analysis comes in.

If there's even a hint that the usage could relate to security mechanisms -
doesn't it mean that SHA-1 MUST be forbidden, and at least SHA256 should be
mandated instead?

We seem to be juggling with this back and forth:

- either this is security-related - then SHA-1 is not suitable and MUST be
replaced with a currently-approved SECURE hash algorithm such as SHA256, or

- it is not security-related - then SHA-1 is too slow and SHOULD be replaced
with a faster algorithm.

Make up your mind - and mark SHA-1 dead in either case.
-- 
Regards,
Uri

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 May 2010 10:15:36 -0700

> We seem to be juggling with this back and forth:

You misunderstand me. The argument for not using SHA-1 (apparently) is
that people feel the need to then explain why it's safe to use here. My
point is that this explanation needs to exist in any case and so we might
as well use the common hash, namely SHA-1.

> replaced with a currently-approved SECURE hash algorithm such as SHA256, or

No, this isn't the case.

> - it is not security-related - then SHA-1 is too slow and SHOULD be replaced

The claim that SHA-1 is too slow to hash a tiny piece of data which would need
to be hashed multiple times in the handshake computation doesn't strike
me as even remotely plausible.

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 10 May 2010 19:21:45 +0200

> other layer of explanation has any force at all.

It has for a fact been hard to get an agreement on this list to use SHA-1
for several reasons already mentioned.
Using FNV was an attempt to find a working solution that would be acceptable
to everyone.

I'm prepared to go with the choice the list can agree on, I still personally
prefer FNV.

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Mon, 10 May 2010 12:29:50 -0500

On 5/10/2010 11:41 AM, Eric Rescorla wrote:
>> So anybody insisting on SHA-1 should

I don't agree that there is an obvious choice of hash algorithm right now:

http://csrc.nist.gov/groups/ST/hash/policy.html
"After 2010, Federal agencies may use SHA-1 only for the following
applications: hash-based message authentication codes (HMACs); key
derivation functions (KDFs); and random number generators (RNGs)."

> question in the WG and I'm stating my opinion.

I didn't mean to imply anyone was insisting, just a rhetorical point.

> to justify the use of a non-cryptographic hash.

Perhaps, but neither does that support SHA-1.

More NIST policy says:
"Federal agencies should stop using SHA-1 for digital signatures,
digital time stamping and other applications that require collision
resistance as soon as practical, and must use the SHA-2 family of hash
functions for these applications after 2010."

I'm just imagining a situation where a seasoned software
developer/manager is having to explain to to some external auditor
lacking a CS degree that "the hash table bucket collisions which could
occur in this part of the code are not the same kind of thing as the
collisions being talked about in this protocol, really".

- Marsh

---

From: "Kemp, David P." <[email-masked]>
Date: Mon, 10 May 2010 13:32:21 -0400

-----Original Message-----
From: Eric Rescorla

> The claim that SHA-1 is too slow to hash a tiny piece of data
> which would need to be hashed multiple times in the handshake
> computation doesn't strike me as even remotely plausible.

Truly implausible: the notion that 5 lines of code is considered
"cruft", while 10 years from now a big algorithm that long ago went the
way of MD4 will not be so considered.

I know you know elegance when you see it, so just give up and admit it.

Dave

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 10 May 2010 19:32:35 +0200

> for SHA-256 to TLS 1.2 about a year ago?

Yes, since I believe people are using SHA-1 in the same way they use MD4
and MD5 today: for interoperability with an deployed base.  Thus, I fail
to understand any argument why SHA-1 would be a more suitable algorithm
than MD5 if the only explanation is "wide use".

I'm not sure discussion is adding anything but subjective opinions at
this point.  I know that implementations of the extension has been
stalled because of this discussion.  Perhaps it is time for a consensus
call to resolve this aspect.

/Simon

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 10 May 2010 10:33:42 -0700

> call to resolve this aspect.

Now this I agree with.

-Ekr

---

From: "Blumenthal, Uri - 0668 - MITLL" <[email-masked]>
Date: Mon, 10 May 2010 13:42:05 -0400

Eric,

My apologies - I indeed misunderstood your argument. Yes an explanation
would be required in any case - I agree.

Honestly I still think that use of SHA-1 here is not justifiable.

My vote is for FNV. I'm OK with whatever brings the consensus.

Tnx!

-- 
Regards,
Uri