IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 11 May 2011 02:31 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
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 16301E06CE for <tls@ietfa.amsl.com>; Tue, 10 May 2011 19:31:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oMlq6NnxZfyr for <tls@ietfa.amsl.com>; Tue, 10 May 2011 19:31:56 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfa.amsl.com (Postfix) with ESMTP id 360FCE06B5 for <tls@ietf.org>; Tue, 10 May 2011 19:31:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1305081116; x=1336617116; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20nmav@gnutls.org,=20pgut001@cs.auckland.ac.nz |Subject:=20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA -1=20algorithms|Cc:=20lloyd@randombit.net,=20tls@ietf.org |In-Reply-To:=20<4DC9627D.4000208@gnutls.org>|Message-Id: =20<E1QJzDG-0006iS-85@login01.fos.auckland.ac.nz>|Date: =20Wed,=2011=20May=202011=2014:31:46=20+1200; bh=711NLJYiJ5zmI7A/3ZZtMtFjRjmpczgB8xT1seEAukE=; b=L1Qekek2VKyM0/Epv1gNe596sCoN67/kU9/jsa3/mAxb3nYmFjJhHJb0 +8N7M3ubSnI0tBk8AJeIzpE4eYy3PrU6R4Zd61c67DABPyW44erf0DxRA cprKrsEtbwpSj8mwXmXP7lbOs2ldm5TBHz9xy8Pqu0jMj83w5hZZB81Z/ Y=;
X-IronPort-AV: E=Sophos;i="4.64,350,1301832000"; d="scan'208";a="61177598"
X-Ironport-HAT: APP-SERVERS - $RELAYED
X-Ironport-Source: 130.216.33.150 - Outgoing - Outgoing
Received: from mf1.fos.auckland.ac.nz ([130.216.33.150]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 May 2011 14:31:46 +1200
Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mf1.fos.auckland.ac.nz with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1QJzDG-0003wW-H6; Wed, 11 May 2011 14:31:46 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1QJzDG-0006iS-85; Wed, 11 May 2011 14:31:46 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: nmav@gnutls.org, pgut001@cs.auckland.ac.nz
In-Reply-To: <4DC9627D.4000208@gnutls.org>
Message-Id: <E1QJzDG-0006iS-85@login01.fos.auckland.ac.nz>
Date: Wed, 11 May 2011 14:31:46 +1200
Cc: tls@ietf.org
Subject: Re: [TLS] DSS with other than SHA-1 algorithms
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
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: Wed, 11 May 2011 02:31:57 -0000

Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:

>I don't really understand. So is ECDSA used for self-signed certificates?

Yes.

>According to me this study would be an argument for the _RSA ecc ciphersuites
>rather than the ECDSA.

Why?  The draft contains the combinations of parameters and options that
everything seems to support and everything seems to get right.  Why the
obsession with _RSA?

(Note, if you can document support for, and interoperability among, Microsoft,
NSS, OpenSSL, and one or two other implementations, for _RSA, I'll be happy to
add it).

To reiterate this yet again, the draft collects in one place the various
combinations of parameters and options that everything I could find supports
and handles correctly.  What it doesn't contain is speculative options that
may or may not work and may or may not be supported.  It is an attempt to
document the status quo and point out the best options to use in order to
maximise interoperability.

Peter.

v2.23.0 | Report a Bug | By Email