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

Viktor Dukhovni <ietf-dane@dukhovni.org> Tue, 06 November 2018 02:24 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 51ED612F295 for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 18:24:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id iiHOCRM02G6v for <tls@ietfa.amsl.com>; Mon, 5 Nov 2018 18:24:30 -0800 (PST)
Received: from straasha.imrryr.org (straasha.imrryr.org []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F99130DCC for <tls@ietf.org>; Mon, 5 Nov 2018 18:24:30 -0800 (PST)
Received: from [] (unknown []) (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 989336B7CF; Mon, 5 Nov 2018 21:24:27 -0500 (EST)
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Reply-To: tls@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Mon, 05 Nov 2018 21:24:26 -0500
To: tls@ietf.org
Message-Id: <79CF87E7-E263-4457-865E-F7BE8251C506@dukhovni.org>
X-Mailer: Apple Mail (2.3445.100.39)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VrGNv1kY3o6BaDub5rknvtwvIe8>
Subject: [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: Tue, 06 Nov 2018 02:24:33 -0000

TL;DR:  Should TLS client abort DHE-RSA handshakes with a peer
certificate that *only* lists:

            X509v3 Key Usage: 
                Key Encipherment, Data Encipherment

(which one might take to mean that only RSA key exchange is allowed,
and DHE-RSA is not, for lack of the DigitalSignature bit?

[ In the unlikely case it matters, the record the certificate
  in question is self-signed, and has a DANE TLSA "3 0 1" record. ]

-- Background:

I am somewhat sympathetic to forbidding RSA key exchange when
"Key Encipherment" is not listed, in order to reduce the risk of
Bleichenbacher-type attacks, but it is not obvious at first blush
why one might the converse restriction...

The reason I ask is that the Haskell TLS library has recently added
enforcement in both directions, and I am finding some SMTP servers
with whose STARTTLS implementation my DANE scan engine no longer

And yet, FWIW, OpenSSL 1.1.1 continues to connect just fine.  Is
this an oversight in OpenSSL?  Overly strict enforcement in Haskell's
Network.TLS?  Should the language in RFC8446 apply also to TLS 1.2
and earlier, where no mention of "keyUsage" is to be found in the
relevant specifications?

The text in 8446 is not crystal clear on the intent.  Is keyUsage
enforcement (absent OID filters from the peer) a MUST?  A SHOULD?
A BCP?  And which directions should it apply in?  That is, does
it make sense to require RSA key transport when DHE appears to
be disallowed?

In appendix E.8 of TLS 1.3 RFC8446 <https://tools.ietf.org/html/rfc8446#appendix-E.8>
we find:

   E.8.  Attacks on Static RSA

   Although TLS 1.3 does not use RSA key transport and so is not
   directly susceptible to Bleichenbacher-type attacks [Blei98], if TLS
   1.3 servers also support static RSA in the context of previous
   versions of TLS, then it may be possible to impersonate the server
   for TLS 1.3 connections [JSS15].  TLS 1.3 implementations can prevent
   this attack by disabling support for static RSA across all versions
   of TLS.  In principle, implementations might also be able to separate
   certificates with different keyUsage bits for static RSA decryption
   and RSA signature, but this technique relies on clients refusing to
   accept signatures using keys in certificates that do not have the
   digitalSignature bit set, and many clients do not enforce this

In 4.2.5 <https://tools.ietf.org/html/rfc8446#section-4.2.5> we
also find:

   This document defines matching rules for two standard certificate
   extensions defined in [RFC5280]:

   -  The Key Usage extension in a certificate matches the request when
      all key usage bits asserted in the request are also asserted in
      the Key Usage certificate extension.

But that's about explicit OID filters from the peer, not a-priori