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

Simon Josefsson <> Mon, 22 February 2010 08:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23F7028C11E for <>; Mon, 22 Feb 2010 00:33:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.731
X-Spam-Status: No, score=-2.731 tagged_above=-999 required=5 tests=[AWL=-0.132, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jJQTNYkM5C2P for <>; Mon, 22 Feb 2010 00:33:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 0715A28C25E for <>; Mon, 22 Feb 2010 00:33:38 -0800 (PST)
Received: from mocca ( []) (authenticated bits=0) by (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o1M8ZQbO028562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 22 Feb 2010 09:35:28 +0100
From: Simon Josefsson <>
To: Brian Smith <>
References: <> <>
OpenPGP: id=B565716F; url=
Date: Mon, 22 Feb 2010 09:35:26 +0100
In-Reply-To: <> (Brian Smith's message of "Fri, 19 Feb 2010 11:52:47 -0600")
Message-ID: <>
User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: "Kemp, David P." <>,
Subject: Re: [TLS] draft-ietf-tls-cached-info-02 / New "Fast-Track" draft
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Feb 2010 08:33:41 -0000

Brian Smith <> writes:

> 1. As long as this web page on the NIST website says, basically,
> "don't use SHA-1 for anything," people will want to disable SHA-1
> whenever they can. It doesn't matter that this page on the website
> isn't the official NIST recommendation on the matter.

I'd like to suggest another argument to support your reasoning: some
FIPS approved crypto libraries no longer export MD5.  I expect the same
to be true for SHA-1 within a few years.  This means that SHA-1 will no
longer be as easily available, for these non-crypto purposes needed in

We noticed this in GnuTLS, that needs MD5 for older TLS versions.  Our
"solution" was to add an optional MD5 implementation to GnuTLS, rather
than always depending on the crypto library for MD5.  This felt strange
to do, but is the logical consequence of deprecating MD5, and eventually
SHA-1, as supported algorithms.

Chosing SHA-256 will give us more time, but we'll likely run into the
same issue eventually anyway.  I believe this suggests that algorithm
agility is useful whenever any crypto-related algorithm is _used_, even
if it is used for non-crypto related purposes.