Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms

Peter Gutmann <pgut001@cs.auckland.ac.nz> Mon, 11 January 2016 23:09 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F9E1AC41A for <tls@ietfa.amsl.com>; Mon, 11 Jan 2016 15:09:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rpp_xXseZKMG for <tls@ietfa.amsl.com>; Mon, 11 Jan 2016 15:09:29 -0800 (PST)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87C201AC419 for <tls@ietf.org>; Mon, 11 Jan 2016 15:09:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1452553769; x=1484089769; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Hzdu2ZIZlJ9t82S0ZOTOmDKr/tEY4H/8y+IcQ38/d1U=; b=AxYGsYeedxAc2KvCJ9H5iKNGXc+RbrNO3kdYnybxvZJOvTRT497eUNeW 1DbJq0xOU4WpYqHt9zXkdhXdTHk3fB7DWU9kCSNX/8sc2P30blk+J0O3k N4DUQwRBX3TVBAu1SrVPB2QBh1LnA97dOZflWaNZr0Zm9VCzVyG2RPBAx uT7vQgMSwvdsGu/YmcF/dj/hEs6VddshZMZQXEYtn3M60L/uwU4yxW/zq widIkgBh5Mzjn7v5F9aWa3kekSa906Fx8zjWQxkwnUFMgTxXk4XhCbxeX pIs2qrwKgtRagS6nFJzZyybQsSGxzrFaCVP5LrNz1+Ris8Xs2ZLHDup01 w==;
X-IronPort-AV: E=Sophos;i="5.20,555,1444647600"; d="scan'208";a="62677016"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxchange10-fe2.UoA.auckland.ac.nz) ([130.216.4.106]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 12 Jan 2016 12:09:27 +1300
Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.153]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.03.0266.001; Tue, 12 Jan 2016 12:09:26 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Kurt Roeckx <kurt@roeckx.be>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms
Thread-Index: AQHRTJ4of0rzW9uDJ0Olh4pPg5BcoZ728Kke
Date: Mon, 11 Jan 2016 23:09:25 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz>
References: <20160111183017.GA12243@roeckx.be>
In-Reply-To: <20160111183017.GA12243@roeckx.be>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/kTaZWZIvbLAw9o5d4gJn2_NzsXI>
Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 11 Jan 2016 23:09:31 -0000

Kurt Roeckx <kurt@roeckx.be>; writes:

>After the SLOTH paper, we should think about starting to deprecate TLS 1.0
>and TLS 1.1 and the SHA1 based signature algorithms in TLS 1.2.

The vulnerabilities shown in the SLOTH paper were based on the fact that
implementations still allow MD5 for authentication/integrity protection, even
if (for example) it's explicitly disabled in the config.  So the problem
wasn't a fault in the protocol, it's buggy implementations (as it was for ones
that allowed 512-bit keys, non-prime primes, and so on).  Throwing out TLS 1.1
based on this seems rather premature.

>As I understand it, they estimate that both TLS 1.2 with SHA1 and TLS 1.0 and
>1.1 with MD5|SHA1 currently require about 2^77 to be broken.  They all depend
>on the chosen prefix collision on SHA1, with the MD5 part in TLS 1.0 and 1.1
>not adding much.

That's presumably based on Joux' multicollisions paper, which also says that
"We also discuss the potential impact of our attack on several published
schemes. Quite surprisingly, for subtle reasons, the schemes we study happen
to be immune to our attack".

More pragmatically, no-one has ever demonstrated any problem with the MD5 ||
SHA1 construct used in TLS, despite there being obvious problems in MD5 and
SHA1 by themselves.

Peter.