Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)

"Jeffrey A. Williams" <jwkckid1@ix.netcom.com> Tue, 11 May 2010 18:08 UTC

Return-Path: <jwkckid1@ix.netcom.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B234B3A6A0F for <tls@core3.amsl.com>; Tue, 11 May 2010 11:08:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.332
X-Spam-Level:
X-Spam-Status: No, score=-0.332 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_50=0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iI47c3qrLacs for <tls@core3.amsl.com>; Tue, 11 May 2010 11:08:45 -0700 (PDT)
Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) by core3.amsl.com (Postfix) with ESMTP id 2551A3A6A83 for <tls@ietf.org>; Tue, 11 May 2010 11:08:44 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=ix.netcom.com; b=NkwaMTRmrmHvo1OwblhFYhPwv+d4IgXy5VSU+30FmelRks9bh9VxqlS7GZZhNXz3; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP;
Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <jwkckid1@ix.netcom.com>) id 1OBtsf-0004qI-NA; Tue, 11 May 2010 14:08:33 -0400
Received: from 99.93.224.206 by webmail.earthlink.net with HTTP; Tue, 11 May 2010 14:08:33 -0400
Message-ID: <262370.1273601313537.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net>
Date: Tue, 11 May 2010 13:08:33 -0500
From: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
To: "Kemp,David P." <DPKemp@missi.ncsc.mil>, tls@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Mailer: EarthLink Zoo Mail 1.0
X-ELNK-Trace: c8e3929e1e9c87a874cfc7ce3b1ad11381c87f5e519606882e54436c1782f2bd038d8d1cb710e141350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 209.86.224.30
Subject: Re: [TLS] Collisions (Re: Consensus Call: FNV vs SHA1)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: "Jeffrey A. Williams" <jwkckid1@ix.netcom.com>
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 May 2010 18:08:46 -0000

David and all,

  good points here.  However the consideration of 
continuing the use of SHA-1 is IMO ill advised.  Further
SHA-2 due to key sizes now in question, is also IMO
ill advised.  FNV is fine, but not perfered.  


-----Original Message-----
>From: "Kemp, David P." <DPKemp@missi.ncsc.mil>
>Sent: May 11, 2010 12:38 PM
>To: tls@ietf.org
>Subject: Re: [TLS] Collisions (Re:  Consensus Call: FNV vs SHA1)
>
>In general, protocols and standardized data structures may make use of
>non-cryptographic hash functions in cases where collisions are
>anticipated and well-handled: i.e. as optimizations (optional) rather
>than as integrity (required) mechanisms.  PKIX AKI/SKI is an example:
>
>   "The authority key identifier extension provides a means of
>   identifying the public key corresponding to the private key 
>   used to sign a CRL. ... This extension is especially useful
>   where an issuer has more than one signing key, either due to
>   multiple concurrent key pairs or due to changeover."
>
>PKIX suggests two SHA-1 -based methods of generating SKIs (including the
>4 bit constant 0100 followed by the 60 least significant bits of the
>SHA-1 hash of a public key), and says "Other methods of generating
>unique numbers are also acceptable."
>
>The same reflexive "broken algorithm" evaluation concerns may exist for
>this use of SHA-1, and FNV would perform the function just as well
>without raising any eyebrows.
>
>If a collision did occur, an implementation would have to do an extra
>signature validation if it first picked the wrong certificate to
>validate a signature.  Not much of a penalty, and one which would have
>to be handled anyway for the case where AKI/SKI is not populated at all.
>
>Dave
>
>
>
>----- Nico wrote: ----
>
>Aside from that, I think FNV is a great hash function.  Its place will
>typically not be in Internet protocols, but in implementations.
>
>[*] I _can_ think of non-cryptographic uses of hash functions in
>    Internet protocols, starting with the use we made in GS2.  But in
>    general I think we'll want to review such uses carefully.  In the
>    case of GS2 it saved us the bother of creating a registry of SASL
>    mechanism names for GSS-API mechanisms.  Here the hash is used to
>    identify cached items, which seems fine provided that collisions are
>    well-handled.  In the GS2 case we decided that collisions were not a
>    problem for us (after all, we could always assign new OIDs to GSS
>    mechanisms that collide).
>
>
>_______________________________________________
>TLS mailing list
>TLS@ietf.org
>https://www.ietf.org/mailman/listinfo/tls

Regards,

Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 294k members/stakeholders and growing, strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of
Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com
Phone: 214-244-4827