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

Martin Rex <mrex@sap.com> Thu, 25 February 2010 20:09 UTC

Return-Path: <mrex@sap.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 4524628C272 for <tls@core3.amsl.com>; Thu, 25 Feb 2010 12:09:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.224
X-Spam-Level:
X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 hd0jV2sz2xdR for <tls@core3.amsl.com>; Thu, 25 Feb 2010 12:09:34 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 9E06128C1EC for <tls@ietf.org>; Thu, 25 Feb 2010 12:09:32 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o1PKBeGD015439 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 25 Feb 2010 21:11:40 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201002252011.o1PKBdRJ015456@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com (Marsh Ray)
Date: Thu, 25 Feb 2010 21:11:39 +0100 (MET)
In-Reply-To: <4B8593FF.7030300@extendedsubset.com> from "Marsh Ray" at Feb 24, 10 03:02:55 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: DPKemp@missi.ncsc.mil, tls@ietf.org
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
Reply-To: mrex@sap.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: Thu, 25 Feb 2010 20:09:35 -0000

Marsh Ray wrote:
> 
> > so if everyone thinks sha256 will be cryptographically
> > viable for the foreseeable future and SHA-1 will soon be impossible
> > to get "approved", then sha256 truncated to 64 bits could be a
> > reasonable MUST-support algorithm.
> 
> Now you'll have to explain why you're taking the output of an
> industrial-strength hash function and throwing away 3/4 of it. :-) Plus,
> it's wasted effort since collisions will be possible to find in any
> 64-bit hash function.


The original purpose of this extension/proposal is to save network
bandwith on repeated _full_ TLS handshakes between peers and
where TLS session caching is not available for whatever reason.

In order to make clear that collision resistance of SHA-1 is
perfectly sufficient, I think the hash value should be
unconditionally truncated to, say, 128-bit (16 octets),
independent of which hash algorithm is used.  This would
also answer any question about whether SHA-1 is sufficient. It is.

Btw. the certificate fingerprinting and public key fingerprinting
algorithms currently also still use SHA-1 (e.g. rfc-5280 4.2.1.2).


I firmly believe that "MUST support SHA-1" is perfectly fine for
this proposal and more than just "good enough" to ship it, provided
that both peers can reliably determine (negotiate) through the
Hello extension whether they support or prefer a newer/different
common hash algorithm before the client starts populating his cache.


-Martin