IETF Logo Mail Archive

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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 27 April 2011 09:22 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 6F35CE0794 for <tls@ietfa.amsl.com>; Wed, 27 Apr 2011 02:22:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.472
X-Spam-Level:
X-Spam-Status: No, score=-3.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, 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 cdImBgH6O3qA for <tls@ietfa.amsl.com>; Wed, 27 Apr 2011 02:22:50 -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 4473CE071F for <tls@ietf.org>; Wed, 27 Apr 2011 02:22:49 -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=1303896171; x=1335432171; h=from:to:subject:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20nmav@gnutls.org,=20tls@ietf.org|Subject:=20Re:=20[ TLS]=20DSS=20with=20other=20than=20SHA-1=20algorithms |In-Reply-To:=20<4DB6FD14.20203@gnutls.org>|Message-Id: =20<E1QF0xG-00064o-8q@login01.fos.auckland.ac.nz>|Date: =20Wed,=2027=20Apr=202011=2021:22:42=20+1200; bh=z6K6qpoUQR6d65BLdy5/K+5DNZqqXLb2eV+0D9zqJXY=; b=o04iDq2BNCSo5am9pEMI3NMj204k/CS0fuZ4VQZiyEa/gjeTJisx10rw +TGMKGjofZw+GJgYmRXFy1BM6zxLbiVsNXKFdJCtkQBJeLTQvf6US2lM4 FLh06VHwQGlp0fCGdOfFwDAPHj9RQsVUYh7HCNbf3iSaFA3zaCxc3OyOj Y=;
X-IronPort-AV: E=Sophos;i="4.64,273,1301832000"; d="scan'208";a="58370050"
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; 27 Apr 2011 21:22:42 +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 1QF0xG-0005r9-HB; Wed, 27 Apr 2011 21:22:42 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1QF0xG-00064o-8q; Wed, 27 Apr 2011 21:22:42 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: nmav@gnutls.org, tls@ietf.org
In-Reply-To: <4DB6FD14.20203@gnutls.org>
Message-Id: <E1QF0xG-00064o-8q@login01.fos.auckland.ac.nz>
Date: Wed, 27 Apr 2011 21:22:42 +1200
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, 27 Apr 2011 09:22:54 -0000

Nikos Mavrogiannopoulos <nmav@gnutls.org> writes:

>* There is no mention of ECDHE_RSA or anon ciphersuites. For me they are the
>most important as they optimize normal DH using existing RSA certificates (in
>the _RSA case).

Nothing (AFAIK) implements these.  The point of the RFC (draft) is to
standardise what are already de facto cipher suite configurations.  If nothing
uses them then they're not really de facto standard configs :-).

>* It doesn't really need to be that aggressive with the previous attempt. If
>this one is better/simpler it will be used in practice and replace the old
>one.

This doesn't replace the existing one, it complements it.  This profiles a set
of de facto standard cipher suites (rather than RFC 4492's Chinese menus) that
are already in common (well, as common as TLS-ECC gets anyway, which is to say
"not very") use.  The point is to have them standardised before TLS-ECC does
get common and the existing interop problems get worse.

Peter.

v2.23.0 | Report a Bug | By Email