Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Benjamin Kaduk <bkaduk@akamai.com> Fri, 03 May 2019 17:20 UTC

Return-Path: <bkaduk@akamai.com>
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 22DE91202FD for <tls@ietfa.amsl.com>; Fri, 3 May 2019 10:20:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.339
X-Spam-Level:
X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com
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 mjP3zfGgwBWT for <tls@ietfa.amsl.com>; Fri, 3 May 2019 10:20:41 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9011202F8 for <tls@ietf.org>; Fri, 3 May 2019 10:20:41 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x43HCqM6009198; Fri, 3 May 2019 18:20:27 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=qvA2GQCwrJrPbUVzbAaE8/XEN8NhKGCk124du96x/40=; b=NdYkMnPrMVZ9R8NYnxWQrcGNOStDdWUKDHofCcwW5ycqq8kGf4PrQOY5KBY4YWv43wZp 3IsjFOj3MH8spn3GX5QAzUvW8skIusMpPwKYw4zsqxt8WfVMdRgLt33sxTNqult2Pff5 nF/qNH4azZWj3GcjZAy/tdVi+o5gvAdS+KU0oQjSiblZcX36+GZZLGGXNxl+SmU88Zbz UvcGjTQKtP1syIvDACQHPvpXRKzt97wbCNLhaLc2dGmgVCuAw0OgaSyQlys/BI4RGWrm Ul5bwOV/9VhxkjHk6Eb4hNNfLk5D1/+UN43bHDsgd6nI4APfag5lwGTHEgyobJ27nUSO 9Q==
Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2s8p13rqxg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 May 2019 18:20:26 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x43HJwcN028129; Fri, 3 May 2019 13:20:25 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint4.akamai.com with ESMTP id 2s4jdxy6v9-1; Fri, 03 May 2019 13:20:25 -0400
Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 17B231FC6B; Fri, 3 May 2019 17:20:24 +0000 (GMT)
Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from <bkaduk@akamai.com>) id 1hMbrD-0006jo-6m; Fri, 03 May 2019 12:20:23 -0500
Date: Fri, 03 May 2019 12:20:22 -0500
From: Benjamin Kaduk <bkaduk@akamai.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Hubert Kario <hkario@redhat.com>, "tls@ietf.org" <tls@ietf.org>, "mrex@sap.com" <mrex@sap.com>
Message-ID: <20190503172022.GH4464@akamai.com>
References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <7d37f7ca-e253-4c95-9cf7-2d16b0b6a0aa@www.fastmail.com> <20190430234952.21F5C404C@ld9781.wdf.sap.corp> <5441930.X76MtM1CnQ@pintsize.usersys.redhat.com> <1556902416424.28526@cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1556902416424.28526@cs.auckland.ac.nz>
User-Agent: Mutt/1.5.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-03_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030111
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-05-03_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1905030111
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GwJf5TryoaQSfYK9g97SNR9jLPI>
Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 03 May 2019 17:20:43 -0000

On Fri, May 03, 2019 at 04:53:44PM +0000, Peter Gutmann wrote:
> Hubert Kario <hkario@redhat.com> writes:
> 
> >And the practical research:
> >https://eprint.iacr.org/2016/131.pdf
> >https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf
> >only confirms that.
> 
> That would be the practical research that says:
> 
>   Due to these constraints, the practical impact of our second preimage attack
>   is limited and its main significance is theoretical.
> 
> This is obviously some strange use of the word "practical" that I wasn't
> previously aware of.
> 
> The other one is a bit too vague to comment on:
> 
>   would lead to an attack on the combiner MD5 || SHA-1 with complexity less
>   than 2^59 (assuming the type 1 collision attack on SHA-1 is fast enough).
> 
> "assuming" and "fast enough" could mean anything ("this leads to an attack on
> AES-GCM with complexity less than 2^59 assuming the key recovery attack on
> AES-128 is fast enough").  However earlier on the paper says:
> 
>   Let’s further assume that a breakthrough in cryptanalysis of SHA-1 brings
>   down the complexity of a collision search attack to 2^52. We know that the
>   best collision search attacks on MD5 are as fast as 2^15
> 
> So what's being shown is that the strength is 2^59 assuming some unspecified
> but pretty spectacular new attack on SHA-1 suddenly turns up, rather than e..g.
> 2^(52+15) = 2^67.
> 
> Even with the appearance of this imaginary new attack, the security of
> MD5||SHA1 is still better than either MD5 or SHA-1 by itself, which is what
> TLS 1.2 specifies.  So I think Martin's point is proven.

I'll make the obligatory note that SHA-2 is fine, and if you decide that
neither MD5 nor SHA1 are in great shape and decide to not use them at
all (whether along or in combination), you are also doing fine.
It's not like publishing another RFC is going to magically change the
behavior of the already deployed systems that people are currently using
these things with, after all, and if someone does change their system,
are really going to recommend they go to TLS 1.0 with MD5||SHA1 rather
than TLS 1.2 with SHA2?

-Ben