Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits

Martin Rex <mrex@sap.com> Wed, 23 March 2011 00:57 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B12BA3A67F4 for <tls@core3.amsl.com>; Tue, 22 Mar 2011 17:57:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.224
X-Spam-Level:
X-Spam-Status: No, score=-10.224 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jfdhz05Uv-s for <tls@core3.amsl.com>; Tue, 22 Mar 2011 17:57:31 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4674B3A67BD for <tls@ietf.org>; Tue, 22 Mar 2011 17:57:30 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p2N0wvc5015793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Mar 2011 01:59:02 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201103230058.p2N0wuwJ022566@fs4113.wdf.sap.corp>
To: shenson@drh-consultancy.demon.co.uk
Date: Wed, 23 Mar 2011 01:58:56 +0100
In-Reply-To: <4D5A8107.8060402@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Feb 15, 11 01:35:03 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] TLSv1.2 with DSA client cert and key size >1024 bits
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Wed, 23 Mar 2011 00:57:32 -0000

Dr Stephen Henson wrote:
> 
> Using SHA-2 algorithms isn't possible in TLS 1.1 and earlier with RSA as they
> hard code the SHA1+MD5 signature.

"not possible in TLS 1.1 and earlier" is an inappropriate determination.

The two possibilities to do this in TLSv1.0 and TLSv1.1 are

  - a specification of an RSA-based TLS cipher suite, intuitively one
    that already uses SHA-256 for the data MAC, to produce the
    "digitally signed struct" with SHA-256 instead of MD5+SHA1

  - a specification of a TLS extension for the purpose of using
    SHA-256 instead of MD5+SHA1 for the "digitally signed struct"
    probably along with a replacement of the "default TLS PRF"
    which is based on an P_MD5() XOR P_SHA1() in TLSv1.0&v1.1
    with a PRF based on P_SHA256() such as in TLSv1.2

-Martin

PS: in case anyone is wondering "why not implement TLSv1.2"?

    - the definition of the signature algorithms extension in rfc-5246
      is pretty much fouled up that I wouldn't count to obtain a sensible
      level of interoperability with it.

    - the clients uncertainty about the hash that will be allowed/required
      for the "digitally signed struct" of the ClientVerify handshake
      message hash

    - the protocol version intolerance for TLSv1.2 in the installed
      base seems worse than the TLS extension intolerance, i.e.
      A TLS record with protocol_version { 0x03, 0x00 } carrying
      a ClientHello with client_version { 0x03, 0x03 } is not advisable
      for clients that do not have application-level dirty hacks to close
      the connection after a failed TLS handshake and restart a new
      connection with a less "sophisiticated" ClientHello.