Re: [TLS] DSS with other than SHA-1 algorithms

Martin Rex <mrex@sap.com> Thu, 10 February 2011 14:03 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 1AFC03A6983 for <tls@core3.amsl.com>; Thu, 10 Feb 2011 06:03:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.174
X-Spam-Level:
X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 YTd9nF0O6hWf for <tls@core3.amsl.com>; Thu, 10 Feb 2011 06:03:40 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id 16D8E3A694F for <tls@ietf.org>; Thu, 10 Feb 2011 06:03:39 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p1AE3dds022874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 10 Feb 2011 15:03:39 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201102101403.p1AE3dBn010841@fs4113.wdf.sap.corp>
To: nmav@gnutls.org
Date: Thu, 10 Feb 2011 15:03:39 +0100
In-Reply-To: <4D539DC8.9070106@gnutls.org> from "Nikos Mavrogiannopoulos" at Feb 10, 11 09:11:52 am
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] DSS with other than SHA-1 algorithms
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: Thu, 10 Feb 2011 14:03:41 -0000

Nikos Mavrogiannopoulos wrote:
> 
>  According to FIPS-186-3 the DSA algorithm might
> be used with hashes other than SHA-1. Moreover
> it mentions:
> "A hash function that provides a lower security strength than the (L, N)
> pair ordinarily should not be used, since this would reduce the
> security strength of the digital signature process to a level no greater
> than that provided by the hash function."
> 
> So what I understand from that is for the parameters
> discussed in the document the SHA variants allowed are:
> 
> L = 1024, N = 160: SHA-1 or better
> L = 2048, N = 224: SHA-224 or better
> L = 2048, N = 256: SHA-256 or better
> L = 3072, N = 256: SHA-256 or better
> 
> How does this apply to TLS 1.0 and 1.1 messages
> "Server Key Exchange" and "Certificate verify"
> that sign the handshake data? How is the peer
> going to understand which hash is being used?

By looking at the AlgId parameters of the DSA public key that
is involved in the signature operation.  The public prime q, whose
length (in bits) is described by the Parameter N above, is part of the
AlgId Parameters of that DSA public key.  (The L refers to the length
(in bits) of the public prime p, also part of the AlgId Parameters).

-Martin