Re: [TLS] SHA-3 in SignatureScheme

Nikos Mavrogiannopoulos <nmav@redhat.com> Mon, 05 September 2016 08:18 UTC

Return-Path: <nmav@redhat.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 672A212B2D6 for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 01:18:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.41
X-Spam-Level:
X-Spam-Status: No, score=-8.41 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.508, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 tFHpQG6RLA0f for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 01:18:01 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A765C12B099 for <tls@ietf.org>; Mon, 5 Sep 2016 01:18:01 -0700 (PDT)
Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 48DAF85546; Mon, 5 Sep 2016 08:18:01 +0000 (UTC)
Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.83]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u858Hxp8007119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Sep 2016 04:18:00 -0400
Message-ID: <1473063478.2851.27.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Eric Rescorla <ekr@rtfm.com>, Dave Garrett <davemgarrett@gmail.com>
Date: Mon, 05 Sep 2016 10:17:58 +0200
In-Reply-To: <CABcZeBOSn-JJgCYPP12wzy3TPEXBGHiCs-qZKosc_cVdwfvFuQ@mail.gmail.com>
References: <7755682.Cma8FBTrvx@pintsize.usersys.redhat.com> <20160902104240.nnt27zfojtywfxpp@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBM-4=ostcAkDhM=jk1aRtXD4dXZKz_ymjShFWmStH3otQ@mail.gmail.com> <201609021125.39108.davemgarrett@gmail.com> <CABcZeBOSn-JJgCYPP12wzy3TPEXBGHiCs-qZKosc_cVdwfvFuQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Mon, 05 Sep 2016 08:18:01 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/LDLJZ2fvfIOfTJFgDMD0eyGJ_gg>
Cc: "tls@ietf.org" <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: Mon, 05 Sep 2016 08:18:03 -0000

On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla wrote:

> > > I also am not following why we need to do this now. The reason we
> > defined SHA-2 in
> > > a new RFC was because (a) SHA-1 was looking weak and (b) we had
> > to make significant
> > > changes to TLS to allow the use of SHA-2. This does not seem to
> > be that case.
> > 
> > I don't think we strictly _need_ to do this now, however I think
> > it's a good idea given that we'll need to do it eventually 
> 
> I'm not sure that that's true.

It is unclear to me what is the intention. Due to the semantics of the
signatureAlgorithms extension in TLS 1.3, if the TLS 1.3 draft doesn't
define SHA3, it effectively _bans_ the usage of SHA3 in all certificate
chains intended to be used by TLS 1.3. If that's the intention then
yes, SHA3 should not be included.

In that case implementations of TLS 1.3 will have to wait for a SHA3
RFC to be published in order to enable the algorithm. That would
introduce a delay, and in certain occasions (e.g., firmware) we will
have TLS 1.3 implementations which may never support SHA3.

IMO, unless there are doubts about SHA3's adoption as a certificate
algorithm, it should be part of the TLS 1.3 spec.

regards,
Nikos