Re: [TLS] SHA-3 in SignatureScheme

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 05 September 2016 10:02 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 F0F6412B39E for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 03:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.408
X-Spam-Level:
X-Spam-Status: No, score=-3.408 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.508] 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 DJ0xP6QuwLV3 for <tls@ietfa.amsl.com>; Mon, 5 Sep 2016 03:02:16 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 049DF127A91 for <tls@ietf.org>; Mon, 5 Sep 2016 03:02:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C1C05F819; Mon, 5 Sep 2016 13:02:13 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id qP5kHIiiOUlU; Mon, 5 Sep 2016 13:02:13 +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-smtp1.welho.com (Postfix) with ESMTPSA id 8FE14C4; Mon, 5 Sep 2016 13:02:13 +0300 (EEST)
Date: Mon, 5 Sep 2016 13:02:12 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
Message-ID: <20160905100212.33j6d6g45gb3ufcx@LK-Perkele-V2.elisa-laajakaista.fi>
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> <1473063478.2851.27.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1473063478.2851.27.camel@redhat.com>
User-Agent: NeoMutt/ (1.7.0)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/vzFK1zBpIUfCVoSPa5D5X1hp6Yg>
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 10:02:18 -0000

On Mon, Sep 05, 2016 at 10:17:58AM +0200, Nikos Mavrogiannopoulos wrote:
> 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.

Huh? Can you explain your logic on how you arrived at that conclusion?

AFAICT, there is nothing preventing assigning new SignatureAlgorithm IDs
from 0705...FDFF range, with possible legacy type specified (for TLS 1.2
compatiblity).

So SHA-3 SignatureSchemes can be added to TLS 1.3 _and_ 1.2 post-hoc.


If the above is wrong, there is IMO a serious issue with the draft.



-Ilari