Re: [TLS] draft-gutmann-tls-eccsuites (Martin Rex) Tue, 08 July 2014 15:16 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B92491B2B1C for <>; Tue, 8 Jul 2014 08:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2vCY45wn90wz for <>; Tue, 8 Jul 2014 08:16:26 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 651321B2B17 for <>; Tue, 8 Jul 2014 08:16:25 -0700 (PDT)
Received: from by (26) with ESMTP id s68FGEgC005344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 8 Jul 2014 17:16:14 +0200 (MEST)
In-Reply-To: <>
To: Hubert Kario <>
Date: Tue, 8 Jul 2014 17:16:14 +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: <>
From: (Martin Rex)
X-SAP: out
Cc: tls <>
Subject: Re: [TLS] draft-gutmann-tls-eccsuites
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Jul 2014 15:16:28 -0000

Hubert Kario wrote:
> Unrelated to the above:
> The draft specifies few TLS1.1-and-lower compatible cipher suites, e.g.:
> My understanding is that you can't use anything but concatenation of MD5|SHA1
> for signing the key exchange with TLS1.1-and-lower. Am I missing something
> or does it apply only the hash used for digital signatures in certificates?

The concatenation of MD5|SHA1 applies only to RSA-signatures
(in digitally signed PKCS#1 v1.5 (block type 2?)) in TLSv1.1 and earlier.

For (EC)DSA, it is traditionally SHA1-only (r+s integers).
But there is a general rule about acceptable hash algorithms for
use with (EC)DSA keypairs, and the key parameters are normally
chosen in a fashion that implies a minimum length of the hash output
(either SHA-1 or one of the SHA-2 algorithms).  rfc4492 says that
the hash could be something other than SHA-1, which I would read as
use the minimum hash length as implied by the (EC)DSA key parameters.