Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2
Hubert Kario <hkario@redhat.com> Tue, 14 May 2019 18:26 UTC
Return-Path: <hkario@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 A09C212017E for <tls@ietfa.amsl.com>; Tue, 14 May 2019 11:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 m2FDJygQfeze for <tls@ietfa.amsl.com>; Tue, 14 May 2019 11:26:15 -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 045F4120046 for <tls@ietf.org>; Tue, 14 May 2019 11:26:09 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B0C603086232; Tue, 14 May 2019 18:26:08 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 313E85D72E; Tue, 14 May 2019 18:26:08 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Daniel Migault <daniel.migault@ericsson.com>
Cc: tls <tls@ietf.org>
Date: Tue, 14 May 2019 20:26:01 +0200
Message-ID: <2162072.cel6DGkFtN@pintsize.usersys.redhat.com>
In-Reply-To: <CADZyTk=oQ+nA6pfrKJB8y15vAogakUu8vB=rnLr5m6z_hDa2Lg@mail.gmail.com>
References: <CAOp4FwRNxx2+MdSqHcrqgA0KkNMaQ29H8K4WBFDAw2AhL+3NKA@mail.gmail.com> <2977635.mFCBgFvPmQ@pintsize.usersys.redhat.com> <CADZyTk=oQ+nA6pfrKJB8y15vAogakUu8vB=rnLr5m6z_hDa2Lg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart1696327.GYAV1sHTnv"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Tue, 14 May 2019 18:26:08 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/qTlDYpSlSe6Mf2zDV_iqOXO-6xo>
Subject: Re: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 14 May 2019 18:26:29 -0000
On Tuesday, 14 May 2019 20:09:36 CEST Daniel Migault wrote: > section 2: > > I am wondering whether SHOULD NOT could be replaced by MUST NOT. On the > one hand, deprecation should be smooth, but on the other hand I am reading > that rfc6194 and rfc6151 already started the deprecation. I would rather > favour MUST NOT. > > Maybe we need to also indicate that MD5 or SHA-1 are ignored by the > receiver. that was the intention behind my suggestion for SHOULD NOT - i.e. the server MUST be able to handle ClientHello that does advertise them, but in practice ignore them based on required handling for SKE and CV > section 3: > > The title section maybe should be Certificate Request (without 's'). > Similarly to the previous section I would suggest MUST NOT and specifying > how the client would behave upon receiving MD5 or SHA-1 as hash. same as above > section 6: > > The current rfc5246 rely on default sha-1 and md5. To ease interoperability > I am wondering if we strongly recommend to provide the signature algorithm > extension in addition to the default sha256. no, sha-1 is the default in case the extension is omitted, but then we also specify that if the extension is omitted now, the negotiation MUST fail the recommendation for sha256 is that it in practice has to be included in the extension as some servers use the extension to select server certificate, so omitting sha256 there will cause the connection to fail this is also partially the reason for a SHOULD NOT instead of MUST NOT for section 2 and 3 – I do not know how those servers handle interaction between SHA-1 missing in the extension and root CA (self-signed certificate) being signed by SHA-1 -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
- [TLS] Proposal to deprecate sha1 and md5 for digi… Loganaden Velvindron
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Martin Thomson
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Loganaden Velvindron
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Hubert Kario
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Daniel Migault
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Loganaden Velvindron
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Hubert Kario
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Hubert Kario
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Daniel Migault
- Re: [TLS] Proposal to deprecate sha1 and md5 for … Loganaden Velvindron