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

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 May 2010 18:06:17 -0700

At the IETF meeting, I promised to write something about the hash algorithm
for cached info.

In short, I prefer SHA-1 to FNV-1. FNV-1 introduces a new algorithm for no
reason other than people might be confused about what SHA-1 is doing
in this case. I realize it's simple but calling SHA-1 is even simpler.
We should just call SHA-1 with no agility.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 7 May 2010 18:14:36 -0700

OK, I'm sending from a different account from where I read the list,
which is why I didn't realize there was an existing thread.

Regardless, after having read the thread, I remain unconvinced that
FNV-1 is the right design.

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Sat, 08 May 2010 09:36:51 +0200

Eric,

Thanks for your input, but it would be great if you let us in on your long
version instead of just stating your opinion.

> We should just call SHA-1 with no agility.

It was you who proposed the syntax that introduced agility for the hash
algorithm (expanding my initial syntax with no agility):

http://www.ietf.org/mail-archive/web/tls/current/msg03331.html

At November IETF 2008 you made a presentation at Saag, recognizing "The Need
for Cryptographically Insecure Hash Functions" for just the reasons that we
see here.

http://www.ietf.org/proceedings/73/slides/saag-0.pdf

I thought that was a great presentation. What has changed your opinion since
then?

Finally, taking your chair hat on, could you advice on how to proceed with
this draft if the majority still prefers FNV?

/Stefan

On 10-05-08 3:14 AM, "Eric Rescorla" <[email-masked]> wrote:

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 8 May 2010 08:04:55 -0700

> version instead of just stating your opinion.

I thought that was the long version: everyone already has SHA-1 in their
stacks. This is just added cruft. What more is there?

> http://www.ietf.org/mail-archive/web/tls/current/msg03331.html

I'm sorry, I don't see the relevance here. I don't recall saying that we needed
agility in that meeting. However, people felt we did and I proposed syntax
that recognized that. The point of that
message was to support multiple types of cached info, not to support
multiple types of hashes. That's why it just supports the "minimal" level
of hash agility, i.e., leting the client tell the server what hash he used.

> I thought that was a great presentation. What has changed your opinion since

I'm not sure my opinion has changed. But here we have a system chock
full of hash functions. One of those is entirely suitable. I don't see the
point in abandoning it for yet another function.

> this draft if the majority still prefers FNV?

I'll let Joe take that. That's why we have two chairs.

-Ekr

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 09 May 2010 12:13:54 +0200

Eric,

> stacks. This is just added cruft. What more is there?

For example the arguments from your own presentation at Saag:

"When cryptographic digests are used, people expect them to be security
critical
    Even worse now that MD5 has been weakened
    Reviewers ask ³what about hash agility?² ³Where¹s the
     security analysis?²
    Need to explicitly disclaim security usages"

I didn't mean to say that you advocated for hash agility, just demonstrate
how true your arguments above are, even in this group of experts.

How relevant is it that calling SHA-1 one is easier, when implementing FNV
is about as hard as writing this e-mail?

/Stefan

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 May 2010 13:53:32 -0700

> is about as hard as writing this e-mail?

I feel like I'm repeating myself.

It's not purely a matter of easier but also of having less cruft in the system.

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.

-Ekr

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 09 May 2010 14:07:18 -0700

> for deviating from our standard SHA-1 using practice is compelling at

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

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 9 May 2010 14:12:30 -0700

On Sun, May 9, 2010 at 2:07 PM, Michael D'Errico <[email-masked]> wrote:
> is for MD5 today?

Yes, there will, and we'll send those who suggest we remove it from this
location the relevant security analysis and that will be that.

> It seems prudent NOT to use SHA-1 precisely for the

Not really. We are (well, were before Stefan changed it) using SHA-1
because it's what everyone uses. Which, incidentally, is precisely the
argument for using it instead of FNV-1, which, by comparison, practically
nobody uses.

-Ekr