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

Peter Gutmann <pgut001@cs.auckland.ac.nz> Wed, 13 April 2011 03:26 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 D1B98E06C3 for <tls@ietfc.amsl.com>; Tue, 12 Apr 2011 20:26:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.48
X-Spam-Level:
X-Spam-Status: No, score=-3.48 tagged_above=-999 required=5 tests=[AWL=0.119, 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 H+p6d1+AjwJU for <tls@ietfc.amsl.com>; Tue, 12 Apr 2011 20:26:53 -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 4DB2AE066A for <tls@ietf.org>; Tue, 12 Apr 2011 20:26:52 -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=1302665214; x=1334201214; h=from:to:subject:cc:in-reply-to:message-id:date; z=From:=20Peter=20Gutmann=20<pgut001@cs.auckland.ac.nz> |To:=20geoffk@geoffk.org,=20mrex@sap.com|Subject:=20Re: =20[TLS]=20DSS=20with=20other=20than=20SHA-1=20algorithms |Cc:=20simon@josefsson.org,=20tls@ietf.org|In-Reply-To: =20<m27hazgev2.fsf@localhost.localdomain>|Message-Id:=20< E1Q9qjC-0005fy-Tk@login01.fos.auckland.ac.nz>|Date:=20Wed ,=2013=20Apr=202011=2015:26:50=20+1200; bh=ZorZ8Pv0aHR2Sbb6RvRzDOlff/NwN3mulavuubHIz/c=; b=npgyE9IjjBA4k2l5+qRiOpJG32Bc4aMgfjapAlSHDiVM5EqC6ue3Xuto vOm4d8Sq9zBYRcZMlzcV+aHGTwBC1InbYtdupkZxJpmt9/EO6+iE4r438 CQjpldGwLAtb7szB0PQEk0kX2qwosFjzspNvpREWKI9v1qwt5/GJbDePP I=;
X-IronPort-AV: E=Sophos;i="4.64,202,1301832000"; d="scan'208";a="56569876"
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 15:26:51 +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 1Q9qjC-0008Vl-JL; Wed, 13 Apr 2011 15:26:51 +1200
Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from <pgut001@login01.cs.auckland.ac.nz>) id 1Q9qjC-0005fy-Tk; Wed, 13 Apr 2011 15:26:50 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: geoffk@geoffk.org, mrex@sap.com
In-Reply-To: <m27hazgev2.fsf@localhost.localdomain>
Message-Id: <E1Q9qjC-0005fy-Tk@login01.fos.auckland.ac.nz>
Date: Wed, 13 Apr 2011 15:26:50 +1200
Cc: simon@josefsson.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 03:26:55 -0000

Geoffrey Keating <geoffk@geoffk.org> writes:

>For future work, I would ignore DSS.

I missed a chance to comment on this earlier, but when someone asked "why 
would you need a TLS 1.3 when TLS 1.2 is infinitely extensible", my response 
would have been "we might need a TLS 1.3 precisely *because* TLS 1.2 is 
infinitely extensible and therefore potentially infinitely complex".  TLS 1.3 
would have the one or two standard cipher suites that everyone uses anway, the 
one or two standard hash algorithms that ..., and a fixed way of doing things 
that would satisfy (literally, from the figures we've seen posted here) about 
99.995% of all users while vastly reducing the complexity (and thereby attack 
surface) of implementations.

Speaking of fixing TLS 1.2 problems, what's the next move for the action list 
of TLS 1.2 issues I posted a week or so back?  Can I get the edit token for TLS 
1.2bis, or should I do a distinct draft that'll then be folded into a future 
TLS 1.2bis?

Peter.