IETF Logo Mail Archive

[TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

"Fries, Steffen" <steffen.fries@siemens.com> Thu, 23 March 2017 14:32 UTC

Return-Path: <steffen.fries@siemens.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 ACDC71243FE for <tls@ietfa.amsl.com>; Thu, 23 Mar 2017 07:32:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.919
X-Spam-Level:
X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 4q8_WpjSsHnf for <tls@ietfa.amsl.com>; Thu, 23 Mar 2017 07:31:59 -0700 (PDT)
Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4D61296E5 for <tls@ietf.org>; Thu, 23 Mar 2017 07:31:58 -0700 (PDT)
Received: from mail1.sbs.de (mail1.sbs.de [192.129.41.35]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id v2NEVufC020650 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <tls@ietf.org>; Thu, 23 Mar 2017 15:31:56 +0100
Received: from DEFTHW99ERJMSX.ww902.siemens.net (defthw99erjmsx.ww902.siemens.net [139.22.70.135]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id v2NEVt9I006683 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <tls@ietf.org>; Thu, 23 Mar 2017 15:31:56 +0100
Received: from DEFTHW99ERCMSX.ww902.siemens.net (139.22.70.70) by DEFTHW99ERJMSX.ww902.siemens.net (139.22.70.135) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 23 Mar 2017 15:31:54 +0100
Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.129]) by DEFTHW99ERCMSX.ww902.siemens.net ([139.22.70.70]) with mapi id 14.03.0339.000; Thu, 23 Mar 2017 15:31:54 +0100
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: Enforcing stronger server side signature/hash combinations in TLS 1.2
Thread-Index: AdKj4jdTMGBzllsXQzCZ8vwWateOaA==
Date: Thu, 23 Mar 2017 14:31:53 +0000
Message-ID: <E6C9F0E527F94F4692731382340B337846DD1B@DENBGAT9EH2MSX.ww902.siemens.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [139.22.70.49]
Content-Type: multipart/alternative; boundary="_000_E6C9F0E527F94F4692731382340B337846DD1BDENBGAT9EH2MSXww9_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hqVO5d2WG9kP1NcNOnaGgtEdA0s>
Subject: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 23 Mar 2017 14:32:00 -0000

Hi all,

according to  TLS 1.2 section 7.4.1.4.1. a client may use the signature_algorithm extension to signal any combinations the client supports, listed in the order of preferences. If the client does not use this extension, the server must use the signature algorithm in combination with SHA1. This may lead to an error on the client side when validating the certificate. Unfortunately the server is not allowed to use this extension, otherwise he could tell the client his preferences according to his security policy. Is there a standard compliant way to utilize SHA256 based certificates on the server side even when a client does not signal additional signature algorithms?

I looked through the mailing list but did not find an immediate answer to my question, but I guess, it must have been discussed already. Thank you in advance for any hint.

Best regards
Steffen

--
Steffen Fries
Siemens AG
Corporate Technology
CT RDA ITS

v2.23.0 | Report a Bug | By Email