IETF Logo Mail Archive

Re: [TLS] Wrapping up cached info

"Joseph Salowey (jsalowey)" <jsalowey@cisco.com> Mon, 17 May 2010 16:34 UTC

Return-Path: <jsalowey@cisco.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 36B993A6AAB for <tls@core3.amsl.com>; Mon, 17 May 2010 09:34:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.33
X-Spam-Level:
X-Spam-Status: No, score=-9.33 tagged_above=-999 required=5 tests=[AWL=-0.220, BAYES_05=-1.11, 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 FCjctfIe4N6t for <tls@core3.amsl.com>; Mon, 17 May 2010 09:34:28 -0700 (PDT)
Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DC15428C18E for <tls@ietf.org>; Mon, 17 May 2010 09:29:53 -0700 (PDT)
Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEACIM8UurR7Ht/2dsb2JhbACdeXGiZZlLglmCNwSDQIt8
X-IronPort-AV: E=Sophos;i="4.53,248,1272844800"; d="scan'208";a="198474086"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 17 May 2010 16:29:46 +0000
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o4HGTkPf018926; Mon, 17 May 2010 16:29:46 GMT
Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 17 May 2010 09:29:46 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 17 May 2010 09:29:44 -0700
Message-ID: <AC1CFD94F59A264488DC2BEC3E890DE50A67C326@xmb-sjc-225.amer.cisco.com>
In-Reply-To: <4BF168A3.40409@extendedsubset.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Wrapping up cached info
Thread-Index: Acr12oyVh6LZskrwQJqy0Mb6pFK61wAAq/DA
References: <C816DA05.66DF%uri@ll.mit.edu> <4BF168A3.40409@extendedsubset.com>
From: "Joseph Salowey (jsalowey)" <jsalowey@cisco.com>
To: Marsh Ray <marsh@extendedsubset.com>, "Blumenthal, Uri - 0668 - MITLL" <uri@ll.mit.edu>
X-OriginalArrivalTime: 17 May 2010 16:29:46.0059 (UTC) FILETIME=[297579B0:01CAF5DE]
Cc: tls@ietf.org
Subject: Re: [TLS] Wrapping up cached info
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: Mon, 17 May 2010 16:34:30 -0000

I agree with Uri, that if you determine you need SHA-256 then you should
plan for hash agility.  TLS 1.2 plans for hash agility.  

What about Nico's proposal where a checksum is used to identify the
cached data and the actual handshake contains the actual data hashed
with the algorithm used in the PRF negotiated with the cipher suite? 

This way we don't have to introduce hash agility into the extension, but
we have cryptographic hash agility where it matters in the Finished
computation.  Does it solve the problem?  

Joe

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of
> Marsh Ray
> Sent: Monday, May 17, 2010 9:03 AM
> To: Blumenthal, Uri - 0668 - MITLL
> Cc: tls@ietf.org
> Subject: Re: [TLS] Wrapping up cached info
> 
> 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
>
http://en.wikipedia.org/wiki/Comparison_of_cryptographic_hash_functions
> lists the only attack against SHA-256 to be against an egregiously
> weakened (24 instead of 64 rounds) variant.
> 
> - Marsh
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email