Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 07 November 2018 07:12 UTC
Return-Path: <ietf-dane@dukhovni.org>
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 2F6A912D4E6 for <tls@ietfa.amsl.com>; Tue, 6 Nov 2018 23:12:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 vKY9wwnsOoYV for <tls@ietfa.amsl.com>; Tue, 6 Nov 2018 23:12:37 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59364127333 for <tls@ietf.org>; Tue, 6 Nov 2018 23:12:37 -0800 (PST)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id 67A056FF78 for <tls@ietf.org>; Wed, 7 Nov 2018 02:12:35 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <m236seg80v.fsf@localhost.localdomain>
Date: Wed, 07 Nov 2018 02:12:34 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <DE213706-285A-4FF4-BA25-3DFC69966BE6@dukhovni.org>
References: <79CF87E7-E263-4457-865E-F7BE8251C506@dukhovni.org> <m236seg80v.fsf@localhost.localdomain>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/RzZnKLzBm1343C9kMTF11K05WFk>
Subject: Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
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: Wed, 07 Nov 2018 07:12:39 -0000
[ Quoted text slightly reordered to put the RSA issue first, as that's the main thing I'm trying to get clarity on, and enabling keyUsage enforcement is causing some interoperability issues now... ] > On Nov 5, 2018, at 11:11 PM, Geoffrey Keating <geoffk@geoffk.org> wrote: > >> TL;DR: Should TLS client abort DHE-RSA handshakes with a peer >> certificate that *only* lists: >> >> X509v3 Key Usage: >> Key Encipherment, Data Encipherment > > Yes, because in DHE-RSA, the RSA key is used for signing, and this is > an encryption-only key. > > As far as I know there's no similar attack on RSA, but I think this is > not a well-examined area. Since the vast majority of certificates in the wild are RSA, and interoperability is a concern, I'd really like to better understand what risk if any posed if one allows a an *RSA* key with a keyUsage of "keyEncipherment" (seen on some live servers that then do DHE-RSA) to be used for "DigitalSignature"? I am only aware of risks in the converse direction. How unreasonable would it be to be more forgiving and allow *RSA* "DigitalSignature" when the keyUsage indicates otherwise? > It's much more important in the DHE-ECDSA case, because using an > encryption-only EC key for signing can lead to key compromise (IIRC). Does anyone have pointers to references for that? FWIW, I've never seen an encryption-only (ECIES?) ECDSA key, I guess could be intended for CMS... In TLSA there's no ECDS keyEncipherment, only ECDHE and fixed ECDH (obsolete). The first goes with a keyUsage of DigitalSignature, the second with keyAgreement. Knowing how fragile ECDSA tends to be to key recovery on nonce re-use or similar issues, I have no reservations enforcing keyUsage for ECDSA. -- Viktor.
- [TLS] Certificate keyUsage enforcement question (… Viktor Dukhovni
- Re: [TLS] Certificate keyUsage enforcement questi… Geoffrey Keating
- Re: [TLS] Certificate keyUsage enforcement questi… Viktor Dukhovni
- Re: [TLS] Certificate keyUsage enforcement questi… Martin Rex
- Re: [TLS] Certificate keyUsage enforcement [whose… Viktor Dukhovni
- Re: [TLS] Certificate keyUsage enforcement questi… David Benjamin
- Re: [TLS] Certificate keyUsage enforcement questi… Geoffrey Keating
- Re: [TLS] Certificate keyUsage enforcement [whose… Peter Gutmann
- Re: [TLS] Certificate keyUsage enforcement [whose… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Certificate keyUsage enforcement questi… Viktor Dukhovni
- Re: [TLS] Certificate keyUsage enforcement questi… Blumenthal, Uri - 0553 - MITLL
- Re: [TLS] Certificate keyUsage enforcement questi… Peter Gutmann
- Re: [TLS] Certificate keyUsage enforcement questi… Viktor Dukhovni
- Re: [TLS] Certificate keyUsage enforcement questi… Peter Gutmann
- Re: [TLS] Certificate keyUsage enforcement questi… Viktor Dukhovni
- Re: [TLS] Certificate keyUsage enforcement questi… Yoav Nir
- Re: [TLS] Certificate keyUsage enforcement questi… Viktor Dukhovni
- Re: [TLS] Certificate keyUsage enforcement questi… Tony Putman
- Re: [TLS] Certificate keyUsage enforcement questi… Viktor Dukhovni
- Re: [TLS] Certificate keyUsage enforcement questi… Andrei Popov
- Re: [TLS] Certificate keyUsage enforcement questi… Nikos Mavrogiannopoulos