Re: [TLS] Fresh results
Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 04 December 2015 07:01 UTC
Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC91B2E33 for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 23:01:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 blJ0m8uH6Rue for <tls@ietfa.amsl.com>; Thu, 3 Dec 2015 23:01:20 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7731B2E29 for <tls@ietf.org>; Thu, 3 Dec 2015 23:01:20 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 6351E284E33; Fri, 4 Dec 2015 07:01:19 +0000 (UTC)
Date: Fri, 04 Dec 2015 07:01:19 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20151204070119.GQ18315@mournblade.imrryr.org>
References: <CACsn0cm41VD40tiwR-sO9piPu01rRkoWKPwHWCKcr5Z9id8kDg@mail.gmail.com> <20151201210257.64f1a7a5@pc1> <1449051281.4345.31.camel@redhat.com> <CANOyrg9AwQHfjZssf0c_=hfHvwLAuq2kFZwkOM7d8tHoHjaQ1A@mail.gmail.com> <24527269-956F-4DFD-8801-1A5331DF0C20@gmail.com> <3C789774-FF2C-4D27-B4A5-0D29E620A65E@gmail.com> <8C9182C4-A92E-4FE0-9576-87007CCE75A7@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8C9182C4-A92E-4FE0-9576-87007CCE75A7@gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/iHnA2ay0YpYjEf1mhunnFBHqJXE>
Subject: Re: [TLS] Fresh results
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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, 04 Dec 2015 07:01:23 -0000
On Fri, Dec 04, 2015 at 07:41:16AM +0100, Karthikeyan Bhargavan wrote: > Of course, the current practice is that KeyUsage is ignored. OpenSSL will > take a certificate that only specified Public Key Encryption and happily use > and accept it for digital signature. Similar flexibility allows ECDSA certs that > should only be used for signing to be used for static ECDH key exchange (leading > to other vulnerabilities). Do we (as in the TLS working group) have the necessary > influence to make sure that KeyUsage is respected? Suppose keyUsage is respected. Who will knowingly shoot themselves in the foot and restrict their RSA certificate to just DHE or just RSA key transport? This looks like an impractical counter-measure. And by the way key usage is enforced by OpenSSL for EC. $ git grep -C3 X509v3_KU_ ssl ssl/ssl_lib.c- X509_check_purpose(x, -1, 0); ssl/ssl_lib.c-# ifndef OPENSSL_NO_ECDH ssl/ssl_lib.c- ecdh_ok = (x->ex_flags & EXFLAG_KUSAGE) ? ssl/ssl_lib.c: (x->ex_kusage & X509v3_KU_KEY_AGREEMENT) : 1; ssl/ssl_lib.c-# endif ssl/ssl_lib.c- ecdsa_ok = (x->ex_flags & EXFLAG_KUSAGE) ? ssl/ssl_lib.c: (x->ex_kusage & X509v3_KU_DIGITAL_SIGNATURE) : 1; ssl/ssl_lib.c- if (!(cpk->valid_flags & CERT_PKEY_SIGN)) ssl/ssl_lib.c- ecdsa_ok = 0; ssl/ssl_lib.c- ecc_pkey = X509_get_pubkey(x); -- ssl/ssl_lib.c- } ssl/ssl_lib.c- if (alg_k & SSL_kECDHe || alg_k & SSL_kECDHr) { ssl/ssl_lib.c- /* key usage, if present, must allow key agreement */ ssl/ssl_lib.c: if (ku_reject(x, X509v3_KU_KEY_AGREEMENT)) { ssl/ssl_lib.c- SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG, ssl/ssl_lib.c- SSL_R_ECC_CERT_NOT_FOR_KEY_AGREEMENT); ssl/ssl_lib.c- return 0; -- ssl/ssl_lib.c- } ssl/ssl_lib.c- if (alg_a & SSL_aECDSA) { ssl/ssl_lib.c- /* key usage, if present, must allow signing */ ssl/ssl_lib.c: if (ku_reject(x, X509v3_KU_DIGITAL_SIGNATURE)) { ssl/ssl_lib.c- SSLerr(SSL_F_SSL_CHECK_SRVR_ECC_CERT_AND_ALG, ssl/ssl_lib.c- SSL_R_ECC_CERT_NOT_FOR_SIGNING); ssl/ssl_lib.c- return 0; -- Viktor.
- [TLS] Fresh results Watson Ladd
- Re: [TLS] Fresh results Hanno Böck
- Re: [TLS] Fresh results Dave Garrett
- Re: [TLS] Fresh results Nikos Mavrogiannopoulos
- Re: [TLS] Fresh results Fabrice Gautier
- Re: [TLS] Fresh results Yoav Nir
- Re: [TLS] Fresh results Dave Garrett
- Re: [TLS] Fresh results Watson Ladd
- Re: [TLS] Fresh results Hanno Böck
- Re: [TLS] Fresh results Fabrice Gautier
- Re: [TLS] Fresh results Karthikeyan Bhargavan
- Re: [TLS] Fresh results Viktor Dukhovni
- Re: [TLS] Fresh results Karthikeyan Bhargavan
- Re: [TLS] Fresh results Hubert Kario
- Re: [TLS] Fresh results David Benjamin
- Re: [TLS] Fresh results Fabrice Gautier