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

David Benjamin <> Wed, 07 November 2018 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9D52812DD85 for <>; Wed, 7 Nov 2018 09:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.721
X-Spam-Status: No, score=-9.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j0HFTol2DlTH for <>; Wed, 7 Nov 2018 09:41:02 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::730]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6991612D4EF for <>; Wed, 7 Nov 2018 09:41:02 -0800 (PST)
Received: by with SMTP id d19so21887530qkg.5 for <>; Wed, 07 Nov 2018 09:41:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=av2EoYlaPy7/Y686yXYoiOX7q9TvU8VoDGnbPzLPOjM=; b=WPct8OxjbdfuDc4bW5JcHVXN+NV1bIHDmzs9qwXeM9VFR/jrKLw12SW0TfDJj6XZAM pX2v4S5CKjltWrWGC6Br7N4AQZ48WpBy5Ghw6YWPGF54/dZdMSAAUEHgh3pDIyfwVhLo spH70lYD4vDqAkFW/coGMF8nZlVBWYxs+sZYM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=av2EoYlaPy7/Y686yXYoiOX7q9TvU8VoDGnbPzLPOjM=; b=stKziN6diDOHZujyP1nu2Y+IHGXBPUNGYh0lwVnjVjIUXbE5BYJs3NsoZq7yIKW4dl siXZEhgp/+m8EqxRqOkFG+Pb8Bfg1uBvImlpSH+A8EwHrYgNCRKsO/Ceyi5xqntC8Emq tv4Ts/IHj0y12+DQB+/riPh6V1Ib0GwSp450iHFYzvJQSYd1EhFSwiSrtkbvdWcd4rYU TI/fx93P1lMoF7fHEDf0FKO555IaAVI7R3UIbDuDBHjuqHEqc1NCOvMoTN94ZswcH5nx JDU7oboL2Y2F/FqsNHMarWxlQ45yR58sTUtb6pMRNVqeHVQlT6IP/qWnXkc9Y1o1YtXO LFDw==
X-Gm-Message-State: AGRZ1gJT1p0A7djtlgp1SLtaA1ehxqbGiQ4Js9vmOxLAPIXVBhve9KXg yAPd035t1Tb3iMnzkvTqAoF6NUxcxW1Z4ndy5bcScU6Zww==
X-Google-Smtp-Source: AJdET5fDFUiXOwXLoLO45jxc7BSCK+8PxQn8cRV+F9f+AID0BuxhE0PcNO8iqJF5FBAJupOOCqYKCfZiK3FlxKkcaWA=
X-Received: by 2002:a37:c891:: with SMTP id t17mr1067885qkl.31.1541612460327; Wed, 07 Nov 2018 09:41:00 -0800 (PST)
MIME-Version: 1.0
References: <> <m236seg80v.fsf@localhost.localdomain> <>
In-Reply-To: <>
From: David Benjamin <>
Date: Wed, 07 Nov 2018 11:40:47 -0600
Message-ID: <>
To: "<>" <>
Content-Type: multipart/alternative; boundary="00000000000014bc87057a169f27"
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: Wed, 07 Nov 2018 17:41:06 -0000

On Wed, Nov 7, 2018 at 1:12 AM Viktor Dukhovni <>

> [ 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 <> 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?

This seems flipped to me. Which attacks do you see enforcing
keyEncipherment blocking? If you are concerned about Bleichenbacher-type
private key oracles, it should be more important to enforce
digitalSignature, and even that's not sufficient in itself (cf. DROWN
affecting non-SSLv2 clients too).

A private key oracle allows both ciphertext decryption *and* signature
forgery, so we need clients to know which forged signatures to reject, and
for an uncompromised path to be possible. Thus, if you believe the server's
RSA key exchange implementation admits a private key oracle and that oracle
is efficient enough for online attacks[*], I believe you need all of the
following for the client to not care:

1. The server uses separate keys for RSA encryption and RSA signing. It
will never use its RSA signing key for RSA encryption.
2. The server key separation is reflected in keyUsage bits, which is
enforced by the client in (EC)DHE_RSA modes.
3. The client doesn't accept RSA key exchange at all.

If all are true, the client will never accept the encryption key and the
signing key is uncompromised, so we're fine. If any of the above are false,
I don't think it works.

If the server shares RSA and (EC)DHE_RSA keys (1), as everyone does, its
one and only key is effectively compromised and there's not a whole lot one
can do, short of fixing or disabling the RSA key exchange implementation on
the server.

If the client ignores keyUsage in (EC)DHE_RSA (2), as most do, the server's
key separation is moot. The client doesn't know to reject a
private-key-oracle-forged signature.

If the client still supports RSA key exchange (3), as most do, none of this
key separation matters, because the attacker can just negotiate RSA key
exchange anyway.

My experience is that typically none of (1), (2), or (3) happen, much less
all, so this is all kind of moot. :-)

Re (2), historically we'd seen issues with MITM proxies minting certs
incorrectly, BoringSSL only enforces key usage for RSA starting TLS 1.3 (it
was new, so get it right from the start) and ECDSA at all versions (only
one value in practice, seems to have worked out). I started gathering more
current metrics a while back but haven't had time to follow-up on this yet.
But as most clients sadly still have to support RSA key exchange (3) and
managing two certificates (1) is onerous for most server, I doubt any
fixing that will help in practice for a while, if ever. It's more an
ecosystem health thing.


[*] If you believe the oracle isn't efficient enough for online attacks,
you probably can just lean on downgrade protection ratcheting you to
(EC)DHE_RSA and call it a day?