Re: [TLS] Fresh results

Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> Fri, 04 December 2015 09:26 UTC

Return-Path: <karthik.bhargavan@gmail.com>
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 708111A036D for <tls@ietfa.amsl.com>; Fri, 4 Dec 2015 01:26:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 fOULy-DVG5pc for <tls@ietfa.amsl.com>; Fri, 4 Dec 2015 01:26:26 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE8D1A0252 for <tls@ietf.org>; Fri, 4 Dec 2015 01:26:26 -0800 (PST)
Received: by wmww144 with SMTP id w144so56709502wmw.0 for <tls@ietf.org>; Fri, 04 Dec 2015 01:26:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:message-id :references:to; bh=zObkN9FWVA8tki0DdCDMLAY8IGj+Y/9r49yk1p/CYtU=; b=Pp9eQ5pPgVjkFNC/lmQD3Wp9gxXpHFfXoHG2U4tPSEs08N1RWTtyx8LqAT0V9WHX2I EjMSzsRjuI6yd5pqsvIbGwAotvYGhRkJ/X90048+Uyc/tNgItrBMlL6uKP3V/27Jx6df C/OPfYN5FiYIGNJu16MikLAklwdR1OO94/tvIf6NF957T1ZrYMMQl4S3dGM1ozxfaRbu 2lUk3GN52cjmXTjAsQIwpyjAkPDgDtO4yl8/XvOiivO5Spw/DF5pEJlWfrRBzPi40zZX xY5KgVSpib5cEe/N3p/tlMhrkN/Key8TZdzKd14noCyV2WZW7IapZfqagvxxU1AW0nyZ LG3w==
X-Received: by 10.194.178.202 with SMTP id da10mr15741316wjc.158.1449221184612; Fri, 04 Dec 2015 01:26:24 -0800 (PST)
Received: from wifi-auth-191208.inria.fr (wifi-auth-191208.inria.fr. [128.93.191.208]) by smtp.gmail.com with ESMTPSA id ft4sm11158393wjb.37.2015.12.04.01.26.22 for <tls@ietf.org> (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Dec 2015 01:26:23 -0800 (PST)
From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
X-Google-Original-From: Karthikeyan Bhargavan <karthikeyan.bhargavan@inria.fr>
Content-Type: multipart/signed; boundary="Apple-Mail=_4AC37C81-D2F1-4056-A064-FFCA0CDD008B"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
X-Pgp-Agent: GPGMail 2.6b2
In-Reply-To: <20151204070119.GQ18315@mournblade.imrryr.org>
Date: Fri, 04 Dec 2015 10:26:21 +0100
Message-Id: <4C7A35C8-7ECF-4E31-BD57-0ECDDED36273@inria.fr>
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> <20151204070119.GQ18315@mournblade.imrryr.org>
To: tls@ietf.org
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/P8yE6oxGRqJ2qV6hiHg5Pe2IXfI>
Subject: Re: [TLS] Fresh results
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Fri, 04 Dec 2015 09:26:28 -0000

> 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.

I guess we have to trade-off between different levels of “shooting oneself in the foot”.
For a company that has a bunch of certificates, one for each domain, separate ECDSA and RSA certificates etc.
spending a few more dollars on different certs for RSA encryption does not seem like a lot.

In any case, the main issue is whether we can get recipients to enforce key usage, not senders.
If a cert explicitly enables key exchange, encryption, and signature, it can be used for all of these.
However, if the cert restricts itself to digital signature, then the client should not use it for RSA encryption.
That way, the server gets to choose whether it wants protection from cross-protocol attacks or not,
and the client will enforce its wishes correctly.

Regarding ECDSA->ECDH cross-protocol attacks, the code that you pointed out in OpenSSL indeed
allows the server to ensure it does not use a sign-only cert for ECDH, but other libraries do not make this distinction.
Moreover, as far as I know, OpenSSL clients do not enforce this key usage restriction (See crypto/x509/x509type.c for the certificate usage rules.)
Neither, for that matter do other TLS clients like NSS etc. This allows attacks like the ECDH downgrade
in [1] and can probably make the ECDSA key recovery attack in [2] quite a bit worse.

From the viewpoint of provable security, I’d be suspicious of any TLS modes that allow the same
long-term keys to be used in multiple different ways. For RSA/EC, there are known attacks. But even otherwise,
their use requires a strong joint security assumption that we don’t really know how to justify.

-K.


[1] https://www.smacktls.com/smack.pdf <https://www.smacktls.com/smack.pdf>
[2] http://euklid.org/pdf/ECC_Invalid_Curve.pdf <http://euklid.org/pdf/ECC_Invalid_Curve.pdf>



> 
> 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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls