Re: [TLS] Wrapping up cached info

Marsh Ray <> Mon, 17 May 2010 16:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B3343A6D5D for <>; Mon, 17 May 2010 09:03:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.463
X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5AJe8lMi9lOu for <>; Mon, 17 May 2010 09:03:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8FCBB3A6D0C for <>; Mon, 17 May 2010 09:02:53 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.68) (envelope-from <>) id 1OE2mD-000MR1-97; Mon, 17 May 2010 16:02:45 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id 3E3DD6048; Mon, 17 May 2010 16:02:43 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1/+m32wr1XePpLyZsskJl2UiFf8nLEbnGw=
Message-ID: <>
Date: Mon, 17 May 2010 11:02:43 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20100216 Thunderbird/3.0.2
MIME-Version: 1.0
To: "Blumenthal, Uri - 0668 - MITLL" <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.0.1
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "" <>
Subject: Re: [TLS] Wrapping up cached info
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, 17 May 2010 16:03:55 -0000

On 5/17/2010 10:33 AM, Blumenthal, Uri - 0668 - MITLL wrote:
> Stefan,
> There is one problem.
> If it turns out that you need SHA256 for security reasons - then you'll also
> need algorithm agility because nobody can guarantee that SHA256 will hold
> (remember - MD4, MD5, SHA1...? :-).

At some point, you have to trust something. After all, any capability
negotiated in the handshake is only as good as the hash which covers it.
TLS 1.2 seems to trust hmac_SHA256.

If, worst-case, SHA-256 turns out to be completely broken, the world
could switch to a stronger scheme for generating those 256 bits
relatively easily.

> Also, do you care how many bits the hash outputs, and how many of
> those bits you use?

I think that's probably the more important thing to fix in the spec.
It's probably a bit easier (should the unfortunate need arise) for
existing implementations to use a different hash of the same width than
it is to change the width of protocol elements.

> Let's provide the analysis and hope that it shows no security issues here.

We don't have to use SHA-256, but it sounds to me like the easiest
choice to explain (and thus get agreement on).

A quick glance at Wikipedia
lists the only attack against SHA-256 to be against an egregiously
weakened (24 instead of 64 rounds) variant.

- Marsh