Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 09 November 2018 06:40 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 E963A130E30 for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 22:40:25 -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 Gur2CqwCsK5t for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 22:40:24 -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 D13C6130DFF for <tls@ietf.org>; Thu, 8 Nov 2018 22:40:23 -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 94B7F3040C0 for <tls@ietf.org>; Fri, 9 Nov 2018 01:40:22 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.1 \(3445.101.1\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <1541744362984.15559@cs.auckland.ac.nz>
Date: Fri, 09 Nov 2018 01:40:21 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: "<tls@ietf.org>" <tls@ietf.org>
Message-Id: <82B55ED0-06D5-416F-8EBE-CCA4808CC32D@dukhovni.org>
References: <79CF87E7-E263-4457-865E-F7BE8251C506@dukhovni.org> <m236seg80v.fsf@localhost.localdomain> <DE213706-285A-4FF4-BA25-3DFC69966BE6@dukhovni.org> <m2y3a4ebau.fsf@localhost.localdomain> <FF305E4A-B304-4C72-9D70-0D65116DD8B9@dukhovni.org> <F04642CF-132E-48EF-B17F-36CC57F245FC@ll.mit.edu> <1541716036588.29769@cs.auckland.ac.nz> <62FC16EB-9567-408E-B3A1-62B868F5A2BB@dukhovni.org> <1541744362984.15559@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1xuNj4LuS_l4Pds4iy4WRYyRstY>
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: Fri, 09 Nov 2018 06:40:26 -0000

> On Nov 9, 2018, at 1:19 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
> 
>> Well, ECDH keys (not really ECDSA) can do key agreement, and EC keys can be
>> used for encryption with ECIES.
> 
> Sure, in theory, but in practice I've never seen an (EC)DH cert used in TLS
> (despite actively looking for one,

Nor have I, and I rather think that introducing fixed-(EC)DH ciphers into
TLS was a mistake, and glad to see them gone in TLS 1.3.

> since it'd be a collectors item for the
> cert collection [0]), and I doubt most implementations could even deal with
> one if they saw one.  Also, I don't think any TLS implementation, or
> specification, does ECIES.  So it's pretty much self-regulating...

And yet I guess the possibility exists that some poor slob deploys a TLS server
with an exotic EC key, that's supposed to be used for fixed-ECDH or CMS key
envelopment.  Does that risk key compromise given how fragile EC signatures
when misused?

I guess I am willing to risk failing a tiny fraction of handshakes in this
case; and rumour has it I'd have some company, so the Haskell TLS library
(where I'm helping the maintainers at the moment) won't stand out from the
pack in being overly strict wrt. ECDSA keyUsage.

The idea is to actually relax the rules a bit from what they've recently
become, as based on the specs they're presently a bit too strict, and I
am trying to dial them back to more practical choices.  If you think that
ECDSA keyUsage enforcement does more harm than good, I could reconsider,
but I am inclined to be more cautious with EC than with RSA.

-- 
-- 
	Viktor.