Re: [TLS] draft-gutmann-tls-eccsuites

mrex@sap.com (Martin Rex) Tue, 08 July 2014 15:16 UTC

Return-Path: <mrex@sap.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 B92491B2B1C for <tls@ietfa.amsl.com>; Tue, 8 Jul 2014 08:16:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vCY45wn90wz for <tls@ietfa.amsl.com>; Tue, 8 Jul 2014 08:16:26 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 651321B2B17 for <tls@ietf.org>; Tue, 8 Jul 2014 08:16:25 -0700 (PDT)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (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: <2138402117.7478111.1404824307081.JavaMail.zimbra@redhat.com>
To: Hubert Kario <hkario@redhat.com>
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: <20140708151614.335231AD94@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7Ltf95IYp589PCkFaaO6IX-jQMc
Cc: tls <tls@ietf.org>
Subject: Re: [TLS] draft-gutmann-tls-eccsuites
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: 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.:
> TLS_ECDHE_ECDSA_P256_SHA256_WITH_AES_128_CBC_SHA
> 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.


-Martin