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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Thu, 08 November 2018 14:37 UTC

Return-Path: <prvs=48507c1ba2=uri@ll.mit.edu>
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 21723128BCC for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 06:37:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 EzO0KdBRmFgi for <tls@ietfa.amsl.com>; Thu, 8 Nov 2018 06:37:24 -0800 (PST)
Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id AAF12126CB6 for <tls@ietf.org>; Thu, 8 Nov 2018 06:37:24 -0800 (PST)
Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id wA8EbN4h045979 for <tls@ietf.org>; Thu, 8 Nov 2018 09:37:23 -0500
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Certificate keyUsage enforcement question (new in RFC8446 Appendix E.8)
Thread-Index: AQHUdXfgFUAluwb9hkW+DFq8DgaTIKVCdmMAgAHFAQCAAQrqgIAAWREAgABWzoA=
Date: Thu, 8 Nov 2018 14:37:21 +0000
Message-ID: <F04642CF-132E-48EF-B17F-36CC57F245FC@ll.mit.edu>
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>
In-Reply-To: <FF305E4A-B304-4C72-9D70-0D65116DD8B9@dukhovni.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.11.0.180909
x-originating-ip: [172.25.1.85]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3624514641_1612729723"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-08_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811080124
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/2A7mRwnoJFDD-Ztf_qZUxixDYgU>
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: Thu, 08 Nov 2018 14:37:27 -0000

Yes to what Viktor proposed.

On 11/7/18, 11:27 PM, "TLS on behalf of Viktor Dukhovni" <tls-bounces@ietf.org on behalf of ietf-dane@dukhovni.org> wrote:

    > On Nov 7, 2018, at 6:07 PM, Geoffrey Keating <geoffk@geoffk.org> 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
         usages.
    
         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.
    
    -- 
    	Viktor.
    
    _______________________________________________
    TLS mailing list
    TLS@ietf.org
    https://www.ietf.org/mailman/listinfo/tls