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.