Re: [TLS] SHA-3 in SignatureScheme

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 02 September 2016 10:44 UTC

Return-Path: <ilariliusvaara@welho.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E30012D832 for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 03:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.448
X-Spam-Level:
X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEjQvKbIDzWR for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 03:44:03 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id D187A12D839 for <tls@ietf.org>; Fri, 2 Sep 2016 03:42:42 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 0FF84105BF; Fri, 2 Sep 2016 13:42:41 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id mBpxjpT6PQRL; Fri, 2 Sep 2016 13:42:40 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 96D2F2310; Fri, 2 Sep 2016 13:42:40 +0300 (EEST)
Date: Fri, 02 Sep 2016 13:42:40 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Hubert Kario <hkario@redhat.com>
Message-ID: <20160902104240.nnt27zfojtywfxpp@LK-Perkele-V2.elisa-laajakaista.fi>
References: <7755682.Cma8FBTrvx@pintsize.usersys.redhat.com> <e4182bf7b91e4a47ac8b5ebd32a4e035@XCH-RTP-006.cisco.com> <201609011922.19048.davemgarrett@gmail.com> <5669028.SHlsS5F4Qu@pintsize.usersys.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <5669028.SHlsS5F4Qu@pintsize.usersys.redhat.com>
User-Agent: NeoMutt/ (1.7.0)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/uBFSy6AzVWSv4O1MCIs7x8-HIPg>
Cc: tls@ietf.org
Subject: Re: [TLS] SHA-3 in SignatureScheme
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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: Fri, 02 Sep 2016 10:44:06 -0000

On Fri, Sep 02, 2016 at 12:08:47PM +0200, Hubert Kario wrote:
> On Thursday, 1 September 2016 19:22:18 CEST Dave Garrett wrote:
> >
> > The reason I see is that we currently specify exactly one valid hash
> > algorithm (in a variety of sizes). The precedent argument is good enough
> > for me. I think adding it in this document is definitely worth considering.
> > I don't want to wait until SHA-2 is considered weak to provide an
> > alternative, if we can avoid it.
> 
> I've created a PR for it: https://github.com/tlswg/tls13-spec/pull/616
> 
> I haven't changed any recommendations, the recommended hashes to implement are 
> still SHA-2 based, and I don't think we should change that given that 
> certificates just now are transitioning to SHA-256 because of incompatibility 
> fears.

Just tweaking the signatures is not enough. There is also the PRF hash,
and using weak hash there has, umm... rather bad consequences.

I also don't see why this should be in TLS 1.3 spec, instead of being
its own spec (I looked up how much process BS it would be to get the
needed registrations: informative RFC would do).


-Ilari