Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft

Marsh Ray <marsh@extendedsubset.com> Wed, 24 February 2010 18:23 UTC

Return-Path: <marsh@extendedsubset.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 579EE28C284 for <tls@core3.amsl.com>; Wed, 24 Feb 2010 10:23:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 zrct1QsYLm-G for <tls@core3.amsl.com>; Wed, 24 Feb 2010 10:23:26 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 2A18928C278 for <tls@ietf.org>; Wed, 24 Feb 2010 10:23:25 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NkLvQ-0003w7-HB for tls@ietf.org; Wed, 24 Feb 2010 18:25:32 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 6D7CD6048 for <tls@ietf.org>; Wed, 24 Feb 2010 18:25:27 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18PRpU06pEUnsWj/cs+32JJfCaNjqFNsLI=
Message-ID: <4B856F19.6080809@extendedsubset.com>
Date: Wed, 24 Feb 2010 12:25:29 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <4B8407D7.9040207@briansmith.org> <C7AB19CF.88B9%stefan@aaa-sec.com> <201002241753.o1OHrxuK015491@stingray.missi.ncsc.mil>
In-Reply-To: <201002241753.o1OHrxuK015491@stingray.missi.ncsc.mil>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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: Wed, 24 Feb 2010 18:23:41 -0000

Kemp, David P. wrote:
> I’d be happier with MUST.  I don’t buy the argument that all code that
> makes up an application must come from a certified crypto library;
> certainly XML parsers, GUI toolkits, and a million other things are
> available to developers, and I find it hard to believe that 20 years
> from now nobody will be able to find some C code somewhere to do SHA-1. 
> If it is impossible to get consensus without a SHOULD, then so be it,
> but that is a cop-out.

The problem with specifying SHA-1 is that it's a recognized as a crypto
algorithm. It's showing its age and various parties are starting to
forbid its use.

It will not be so fun to convince reviewers that "yes we're using SHA-1
but not in a way that really matters."

> I agree with Martin and Brian that all hashes including SHA-1 should be
> truncated.  To make it impossible for developers to miss (and to save a
> few bits of bandwidth) it should be truncated to less than 20 octets. 
> I’d suggest 8 octets, but pick your favorite number (8, 12, 16) less
> than 20.

If all you need is a 64-bit checksum for data-structure-style hashing
and indexing, use any old old-fashioned checksum algorithm.

This would be simple for everyone to implement and it clearly
communicates your design intent (that the security of the design does
not depend on any properties of this value's calculation).

Using a weakened form of a partially-broken and deprecated cryptographic
algorithm seems like it could provoke a lot of useless discussion.

- Marsh