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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 13 April 2011 06:20 UTC

Return-Path: <pgut001@login01.cs.auckland.ac.nz>
X-Original-To: tls@ietfc.amsl.com
Delivered-To: tls@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A1373E0687 for <tls@ietfc.amsl.com>; Tue, 12 Apr 2011 23:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.487
X-Spam-Level:
X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AvOGeGsQ9dgS for <tls@ietfc.amsl.com>; Tue, 12 Apr 2011 23:20:08 -0700 (PDT)
Received: from mx2-int.auckland.ac.nz (mx2-int.auckland.ac.nz [130.216.12.41]) by ietfc.amsl.com (Postfix) with ESMTP id 8E8FFE065A for <tls@ietf.org>; Tue, 12 Apr 2011 23:20:07 -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=1302675609; x=1334211609; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20ekr@rtfm.com,=20pgut001@cs.auckland.ac.nz|Subject: =20Re:=20[TLS]=20DSS=20with=20other=20than=20SHA-1=20algo rithms|Cc:=20geoffk@geoffk.org,=20mrex@sap.com,=20simon@j osefsson.org,=20tls@ietf.org|In-Reply-To:=20<BANLkTinGVXV EFuWC80KFzfv-u-XciJ62ww@mail.gmail.com>|Message-Id:=20<E1 Q9tQq-0006Q4-VU@login01.fos.auckland.ac.nz>|Date:=20Wed, =2013=20Apr=202011=2018:20:04=20+1200; bh=jUGEbeE1o5quApXx4KHDoCaT7Sb1HlKjApyzUYrHsP0=; b=LnrBZ9gq2gCcPXFieffau/CAWcrGGj/iEFMLLtgfGZy8G3dvIrIFNYJU IFbv0pI6+SRzaP5OLn+uXw911bBQQj73kBYjJNdoHeB57woA6VCvnw1NM VTTV4sQ0BjD1hVR73grDxh/RJd2URVZPPAQTahMGiABBq1oUX9/vlZ8zg c=;
X-IronPort-AV: E=Sophos;i="4.64,202,1301832000"; d="scan'208";a="56604828"
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; 13 Apr 2011 18:20:05 +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 1Q9tQr-0006gx-GC; Wed, 13 Apr 2011 18:20:05 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Q9tQq-0006Q4-VU; Wed, 13 Apr 2011 18:20:04 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: ekr@rtfm.com, pgut001@cs.auckland.ac.nz
In-Reply-To: <BANLkTinGVXVEFuWC80KFzfv-u-XciJ62ww@mail.gmail.com>
Message-Id: <E1Q9tQq-0006Q4-VU@login01.fos.auckland.ac.nz>
Date: Wed, 13 Apr 2011 18:20:04 +1200
Cc: simon@josefsson.org, geoffk@geoffk.org, 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, 13 Apr 2011 06:20:09 -0000

Eric Rescorla <ekr@rtfm.com> writes:

>1. I'm not convinced that the requirement that relying parties check the 
>signature_algorithm should in fact be relaxed.

This despite the fact that every single person who responded considered it a 
really bad idea (and some were far more vigorous in their comments than just 
"bad idea"), and that no implementation actually checks it?  This sort of
approach sounds more like PKIX than TLS.

>3. The ECC issues you raise are not issues in 5246 at all, since ECC is 
>specified in a different document (4492).

5246 claims to be an update to 4492 (line 4 of the doc), and a far more 
drastic one than just adding a few new cipher suites since it's not 
backwards-compatible with 4492.  This would be just another update of 4492,
and one that's fully backwards-compatible.

Peter.