IETF Logo Mail Archive

Re: [TLS] SHA-3 in SignatureScheme

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Fri, 02 September 2016 13:29 UTC

Return-Path: <prvs=8053eb0eee=uri@ll.mit.edu>
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 C61DC12D87F for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 06:29:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.747
X-Spam-Level:
X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, UNPARSEABLE_RELAY=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 DnN5KS0SeCnj for <tls@ietfa.amsl.com>; Fri, 2 Sep 2016 06:29:30 -0700 (PDT)
Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8E37C12D87C for <tls@ietf.org>; Fri, 2 Sep 2016 06:29:30 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id u82DPoaa006575; Fri, 2 Sep 2016 09:25:50 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Hubert Kario <hkario@redhat.com>
Thread-Topic: [TLS] SHA-3 in SignatureScheme
Thread-Index: AdIFHgf/OWP+vPLKs0GIS/iOWjsWWg==
Date: Fri, 02 Sep 2016 13:29:28 +0000
Message-ID: <20160902132937.18292816.43149.88607@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="===============1684456817=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-09-02_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=inbound_notspam policy=inbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1609020179
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/EJIpWxYPXyFGMb1A8Bc7ESSbOTE>
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: Fri, 02 Sep 2016 13:29:33 -0000

Speaking of PRF hash, I want to bring up the fact that‎ SHA-3 is a better PRF by design, as that was one of the explicitly stated competition requirements (unlike MD*, SHA-1, and SHA-2).

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Ilari Liusvaara
Sent: Friday, September 2, 2016 06:44
To: Hubert Kario
Cc: tls@ietf.org
Subject: Re: [TLS] SHA-3 in SignatureScheme

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email