Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2
"Fries, Steffen" <steffen.fries@siemens.com> Thu, 23 March 2017 15:37 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 A06521296ED for <tls@ietfa.amsl.com>; Thu, 23 Mar 2017 08:37:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.918
X-Spam-Level:
X-Spam-Status: No, score=-6.918 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, URIBL_BLOCKED=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 gWy-ADhrA0Zd for <tls@ietfa.amsl.com>; Thu, 23 Mar 2017 08:37:07 -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 05285129781 for <tls@ietf.org>; Thu, 23 Mar 2017 08:37:05 -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 v2NFb3SM006632 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <tls@ietf.org>; Thu, 23 Mar 2017 16:37:03 +0100
Received: from DEFTHW99ERLMSX.ww902.siemens.net (defthw99erlmsx.ww902.siemens.net [139.22.70.136]) by mail1.sbs.de (8.15.2/8.15.2) with ESMTPS id v2NFb3bm000827 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <tls@ietf.org>; Thu, 23 Mar 2017 16:37:03 +0100
Received: from DENBGAT9ER1MSX.ww902.siemens.net (139.22.70.87) by DEFTHW99ERLMSX.ww902.siemens.net (139.22.70.136) with Microsoft SMTP Server (TLS) id 14.3.339.0; Thu, 23 Mar 2017 16:37:03 +0100
Received: from DENBGAT9EH2MSX.ww902.siemens.net ([169.254.6.129]) by DENBGAT9ER1MSX.ww902.siemens.net ([139.22.70.87]) with mapi id 14.03.0339.000; Thu, 23 Mar 2017 16:37:02 +0100
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: TLS WG <tls@ietf.org>
Thread-Topic: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2
Thread-Index: AQHSo+tRbCE70GuRKkiIdy7OdMXyAg==
Date: Thu, 23 Mar 2017 15:37:02 +0000
Message-ID: <E6C9F0E527F94F4692731382340B337846DE14@DENBGAT9EH2MSX.ww902.siemens.net>
References: <E6C9F0E527F94F4692731382340B337846DD1B@DENBGAT9EH2MSX.ww902.siemens.net> <4DD1F233-D659-4F79-9ADA-BC31A49DA653@dukhovni.org> <CABcZeBNu_9EHKWFzWFvtcUZ5GA5SQ8DbjHqEvn4yjBLH6=yuXg@mail.gmail.com>
In-Reply-To: <CABcZeBNu_9EHKWFzWFvtcUZ5GA5SQ8DbjHqEvn4yjBLH6=yuXg@mail.gmail.com>
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_E6C9F0E527F94F4692731382340B337846DE14DENBGAT9EH2MSXww9_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ze2wyzzgLowdLDvkrKBYBXpk0x4>
Subject: Re: [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 15:37:10 -0000
Hi Erik, based on your reply my conclusion is that - there is no (standard compliant) way for a server to use a SHA256 based certificate for server side authentication in cases where the client does not provide the signature_algorithm extension - clients should always use the signature algorithm extension to ensure the server can apply a certificate with the appropriate crypt algorithms Best regards Steffen On Thu, Mar 23, 2017 at 7:39 AM, Viktor Dukhovni <ietf-dane@dukhovni.org<mailto:ietf-dane@dukhovni.org>> wrote: > On Mar 23, 2017, at 10:31 AM, Fries, Steffen <steffen.fries@siemens.com<mailto:steffen.fries@siemens.com>> wrote: > > 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. The signature algorithm is primarily about signatures made as part of the TLS handshake, and not so much signatures in certificates. This does not seem consistent with https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.2 "If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension." I appreciate that there are people who feel that this rule is bad, and to some extent it has been relaxed in 1.3, but I think the text is pretty clear here. > If the client does not use this extension, the server must use the > signature algorithm in combination with SHA1. For signing the TLS key exchange, however, it should still present whatever certificate chain it has, even if that chain employs SHA256. It is exceedingly unlikely these days that a client will not support SHA256 signatures in the certificate chain. Yes, that's generally true. Though a TLS 1.2 client which does not offer SHA-256 in its ClientHello but accepts SHA-256 is broken. So, this should generally only happen with TLS 1.1 and below. > Unfortunately the server is not allowed to use this extension, otherwise > he could tell the client his preferences according to his security policy. The protocol (as it should) lacks the additional round-trips necessary for the server to initiate signature algorithm negotiation. I'm not sure quite what the OP Is trying to achieve here. For certificates offered by the server, the client just tells you what algorithms it will accept for no negotiation is needed. For certificates offered by the client, the server tells the client what algorithms it will accept in the CertificateRequest. https://tools.ietf.org/rfcmarkup?doc=5246#section-7.4.4 -Ekr
- [TLS] Enforcing stronger server side signature/ha… Fries, Steffen
- Re: [TLS] Enforcing stronger server side signatur… Viktor Dukhovni
- Re: [TLS] Enforcing stronger server side signatur… Eric Rescorla
- Re: [TLS] Enforcing stronger server side signatur… Fries, Steffen
- Re: [TLS] Enforcing stronger server side signatur… Fries, Steffen
- Re: [TLS] Enforcing stronger server side signatur… Martin Rex
- Re: [TLS] Enforcing stronger server side signatur… Andrei Popov
- Re: [TLS] Enforcing stronger server side signatur… Eric Rescorla
- Re: [TLS] Enforcing stronger server side signatur… Eric Rescorla
- Re: [TLS] Enforcing stronger server side signatur… Andrei Popov
- Re: [TLS] Enforcing stronger server side signatur… Martin Rex
- Re: [TLS] Enforcing stronger server side signatur… Eric Rescorla
- Re: [TLS] Enforcing stronger server side signatur… Eric Rescorla
- Re: [TLS] Enforcing stronger server side signatur… Peter Gutmann
- Re: [TLS] Enforcing stronger server side signatur… Peter Gutmann
- Re: [TLS] Enforcing stronger server side signatur… Viktor Dukhovni
- Re: [TLS] Enforcing stronger server side signatur… Martin Thomson
- Re: [TLS] Enforcing stronger server side signatur… Viktor Dukhovni
- Re: [TLS] Enforcing stronger server side signatur… Fries, Steffen
- Re: [TLS] Enforcing stronger server side signatur… Martin Rex
- Re: [TLS] Enforcing stronger server side signatur… Salz, Rich
- Re: [TLS] Enforcing stronger server side signatur… Eric Rescorla
- Re: [TLS] Enforcing stronger server side signatur… Martin Rex
- Re: [TLS] Enforcing stronger server side signatur… Martin Rex
- Re: [TLS] Enforcing stronger server side signatur… Ryan Sleevi
- Re: [TLS] Enforcing stronger server side signatur… Martin Rex
- Re: [TLS] Enforcing stronger server side signatur… Ryan Sleevi
- Re: [TLS] Enforcing stronger server side signatur… Michael StJohns
- Re: [TLS] Enforcing stronger server side signatur… Martin Rex
- Re: [TLS] Enforcing stronger server side signatur… Eric Rescorla