Re: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage) (Martin Rex) Sat, 12 October 2013 04:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C81121F9D74 for <>; Fri, 11 Oct 2013 21:50:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -9.699
X-Spam-Status: No, score=-9.699 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HPYZjmRJaHFG for <>; Fri, 11 Oct 2013 21:50:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4669421F9BD5 for <>; Fri, 11 Oct 2013 21:50:14 -0700 (PDT)
Received: from by (26) with ESMTP id r9C4o16h007181 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 12 Oct 2013 06:50:01 +0200 (MEST)
In-Reply-To: <>
To: =?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?= <>
Date: Sat, 12 Oct 2013 06:50:01 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="ISO-8859-1"
Message-Id: <>
From: (Martin Rex)
X-SAP: out
Cc: "<>" <>
Subject: Re: [TLS] Enforcing keyUsage restrictions (was Re: Safe ECC usage)
X-Mailman-Version: 2.1.12
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: Sat, 12 Oct 2013 04:50:24 -0000

Manuel Pégourié-Gonnard wrote:
> Santosh Chokhani wrote:
> >
> > DS bit for RSA based TLS server is not appropriate since the Server key is
> > used by the client to encrypt and never used for digital signature
> > verification.
> Your seem to have RSA key exchange in mind, while Brian was talking about
> ECDHE_RSA or DHE_RSA key exchanges, where the server's RSA key is used to sign
> the parameters in the ServerKeyExchange message. The point was precisely that,
> if the keyUsage bits were respected, then setting only DS would force to use
> only forward secret key exchanges with this certificate.

It might result in more TLS implementations to work around the interop
problem and disable keyUsage checks like Peter did.

Really, the best that could happen to the NSA is that everyone starts
using ECDHE with Nist curves, aka Suite B.  It just would not make sense
(and amount to a huge waste of tax dollars) if these were _not_ bugged!

The defects in (EC)DSA look rather accidental to me, and EC_Dual_DRNG was
deliberatly set up to deceive folks on what was _really_ subverted.
Considering how it is being used, ECDHE as part of Suite B is the
single point of failure that is by far the most convenient, because
it will work for large-scale passive eavesdropping.

The original "digitally-signed" in SSLv3 and TLSv1.0 for RSA was using
a conservative design, since it combined two hash algorithms (SHA1+MD5).
In TLSv1.2 this was artificially neutered -- (rsa,md5) is a valid signature
algorithm according to the TLSv1.2 spec, but ridiculously weak.

If we were to "fix" TLS, then we should use combinations of algorithms
more often, rather than less.  Such as making it possible to use
an RSA premaster secret XORed with a DHE or ECDHE shared secret.