Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature

mrex@sap.com (Martin Rex) Fri, 20 September 2013 13:38 UTC

Return-Path: <mrex@sap.com>
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 5A13E21F9A19 for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 06:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.91
X-Spam-Level:
X-Spam-Status: No, score=-9.91 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mw1QEJEnNGza for <tls@ietfa.amsl.com>; Fri, 20 Sep 2013 06:38:03 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C549721F99FB for <tls@ietf.org>; Fri, 20 Sep 2013 06:37:56 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r8KDbsw8002340 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 20 Sep 2013 15:37:54 +0200 (MEST)
In-Reply-To: <CALTJjxHSak1aPWms3vct3nq5Ls9MpBHHH-2wkXh8Up6rrBHjhw@mail.gmail.com>
To: Wan-Teh Chang <wtc@google.com>
Date: Fri, 20 Sep 2013 15:37:54 +0200 (CEST)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20130920133754.2AFE51A98B@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] which alert for TLS client cert w/o keyUsage digitalSignature
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: mrex@sap.com
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: <http://www.ietf.org/mail-archive/web/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, 20 Sep 2013 13:38:07 -0000

Wan-Teh Chang wrote:
> 
> RFC 4492 says:
> 
>           Key Exchange Algorithm  Server Certificate Type
>           ----------------------  -----------------------
> 
>           ...
> 
>           ECDHE_RSA               Certificate MUST contain an
>                                   RSA public key authorized for
>                                   use in digital signatures.  It
>                                   MUST be signed with RSA.
> 
> Note: I don't understand why RFC 4492 says "It MUST be signed with RSA."


On my scorecard, this is a clear defect of rfc4492.  But it is a defect
that it inherited from a non-obvious statement in TLSv1.0 (rfc2246):

http://tools.ietf.org/html/rfc2246#section-7.4.2

  7.4.2. Server certificate

   Meaning of this message:
       The certificate type must be appropriate for the selected cipher
       suite's key exchange algorithm, and is generally an X.509v3
       certificate. It must contain a key which matches the key exchange
*      method, as follows. Unless otherwise specified, the signing
*      algorithm for the certificate must be the same as the algorithm
       for the certificate key.


This unreasonable restriction is *NOT* present in SSLv3:

http://tools.ietf.org/html/rfc6101#section-5.6.2

5.6.2. Server Certificate


   If the server is to be authenticated (which is generally the case),
   the server sends its certificate immediately following the server
   hello message.  The certificate type must be appropriate for the
   selected cipher suite's key exchange algorithm, and is generally an
   X.509.v3 certificate (or a modified X.509 certificate in the case of
   FORTEZZA(tm) [FOR]).  The same message type will be used for the
   client's response to a certificate request message.


So this artificial limitation is a hidden backwards-incompatible change
in TLSv1.0, that should have never existed in the first place--and
I'm not aware of a TLS implementation which "enforces" this stupidity.


What is particularly strange about this defect is that EVERYONE has
been using RSA certificates for SSL&TLS Servers since 1996, and the
TLSv1.0 spec that was published in 1999 has (due to crypto-political
reasons of that area) mandatates a DHE_DSS cipher suite:

  9. Mandatory Cipher Suites

TLSv1.0  http://tools.ietf.org/html/rfc2246#section-9

  TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA


TLSv1.1  http://tools.ietf.org/html/rfc4346#section-9

  TLS_RSA_WITH_3DES_EDE_CBC_SHA


This limitation should be seen as a guidance to CAs to promote interop
rather than a self-imposed crippling of TLS implementations.

-Martin