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

Viktor Dukhovni <> Thu, 08 November 2018 04:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A8BE1276D0 for <>; Wed, 7 Nov 2018 20:26:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id diBXhA1Sajay for <>; Wed, 7 Nov 2018 20:26:44 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CB92D124C04 for <>; Wed, 7 Nov 2018 20:26:43 -0800 (PST)
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 6D9CE7571E for <>; Wed, 7 Nov 2018 23:26:41 -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 <>
In-Reply-To: <m2y3a4ebau.fsf@localhost.localdomain>
Date: Wed, 07 Nov 2018 23:26:40 -0500
Content-Transfer-Encoding: quoted-printable
Reply-To: "<>" <>
Message-Id: <>
References: <> <m236seg80v.fsf@localhost.localdomain> <> <m2y3a4ebau.fsf@localhost.localdomain>
To: "<>" <>
X-Mailer: Apple Mail (2.3445.101.1)
Archived-At: <>
Subject: Re: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Nov 2018 04:26:46 -0000

> On Nov 7, 2018, at 6:07 PM, Geoffrey Keating <> wrote:
> n general, though, what you're asking is "The CA signing this key has
> instructed that I do not accept signatures made with it.  Is it OK to
> accept signatures made with it?" It's really hard to see how the
> answer to that could generally be 'yes'.

Thanks for everyone's input, this has been very helpful.  The approach
I'm inclined to take is as follows:

1. Always enforce key usage for your own certificate, ensuring key
   separation as provisioned at the time of key/certificate creation.
   This also maximizes opportunities for problems to be detected early
   and fixed.

2. Always enforce peer certificate key usage (separation) for ECDSA.
   ECDSA keys are more brittle when misused.

3. Enforce RSA peer certificate key usage when RSA key transport is locally
   disabled, allowing only (EC)DHE-RSA.  This is always the case with TLS 1.3,
   but for TLS <= 1.2 subject to the enabled ciphers.

The rationale for 3 is as follows:

   * The primary responsibility for doing key separation right falls on the
     key holder (as in 1).  If that's always done correctly, the peer has
     nothing to second-guess.

   * If the key holder has no key separation, and makes key recovery
     possible through some sort of side-channel, then the attacker who
     recovers the key can always misuse that key via whichever key
     exchange is allowed by the certificate, when all are accepted by
     the client.

     Therefore, if the client supports both RSA key exchange and (EC)DHE-RSA,
     the attacker wins regardless of any effort by the client to enforce key

     Which leaves the case where the client only accepts (EC)DHE-RSA (as with
     TLS 1.3 or TLS 1.2 with the RSA key exchange features disabled).  In that
     case, if the attacker is able to compromise a server key constrained to
     "keyEncipherment", but cannot obtain a fraudulent certificate, then he'd have
     a certificate for just "keyEncipherment" which the client will refuse to
     honour for "digitalSignature".  And so the client actually gets some measure
     of protection by doing keyUsage enforcement.

This approach also has the advantage that legacy cases continue to (mis)behave
like they always did, but the strictness rises to match the client's protocol
preferences wether through use of TLS 1.3 (fresh start, fresh constraints) or
by restricting TLS 1.2 ciphers in a way that makes keyUsage enforcement a
practical counter-measure to at least some potential attacks.