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

Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> Tue, 12 January 2016 13:49 UTC

Return-Path: <karthik.bhargavan@gmail.com>
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 307131AD35D for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 05:49:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 lZijrYb-WCn8 for <tls@ietfa.amsl.com>; Tue, 12 Jan 2016 05:49:49 -0800 (PST)
Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4020D1AD35C for <tls@ietf.org>; Tue, 12 Jan 2016 05:49:49 -0800 (PST)
Received: by mail-wm0-x235.google.com with SMTP id l65so252732770wmf.1 for <tls@ietf.org>; Tue, 12 Jan 2016 05:49:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QtGO/UkgjDlPUlYocqY7Fe5LVwm7f5zXFNr997tOa54=; b=jQ9FPzYEYW0xOAZAzbPgUv6HqUlKf+dbhHYBwaZ2MCLpExsqVg+3vCJBhaXl8x8SkY EF/0YH6OexUDozzoWlvHnb0vXlvfnE/89NBoZJpGoDvwngiSTU8LsOZDKONLy8XmZsGd 4H9PedW0iSVezRvS3g4vDeBTR5yGuyqWLoauD2UzUwZ0u/OUqmjAuvcvIYqhjswxCATm Xu1gDVbiN21XxyK7JB7LI/MyPPAUm+loHQ8v0lgEKXc2HTB60sWOBvP0wfRpdY6E1ydc 6GwRig9zefRQJ9k4lXyeSOxrOIN0Pz4XLFipErULhQCmJU1qEA/c723Y/OSt+1M+sw9P ARzQ==
X-Received: by 10.194.79.37 with SMTP id g5mr43291428wjx.89.1452606587860; Tue, 12 Jan 2016 05:49:47 -0800 (PST)
Received: from [128.93.85.191] ([128.93.85.191]) by smtp.gmail.com with ESMTPSA id id1sm123813508wjb.19.2016.01.12.05.49.46 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 12 Jan 2016 05:49:46 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>
In-Reply-To: <20160112132431.237AA1A3E4@ld9781.wdf.sap.corp>
Date: Tue, 12 Jan 2016 14:49:46 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C735F785-F38B-4620-B78F-5D5C57FAA36D@gmail.com>
References: <20160112132431.237AA1A3E4@ld9781.wdf.sap.corp>
To: mrex@sap.com
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/hgWYM-7efFKDv_m8PTTiipfIU4I>
Cc: "tls@ietf.org" <tls@ietf.org>
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: Tue, 12 Jan 2016 13:49:51 -0000

> I'm also wondering whether it might be misleading to lump the
> (in)significance of the currently known collisions for HMAC-SHA1
> and HMAC-MD5 together with the (in)significance for 
> (general, low-frequent) digital signatures and together with
> PKCS#10 & Certificate-issuance design flaw that enables a
> mere collision attack to achieve what would normally require
> a successful 2nd preimage attack.

I couldn’t really parse this sentence very well, but here are some clarification.

As far as we know, HMAC-MD5 and HMAC-SHA1 are still sufficiently strong MAC functions,
and their use in the TLS Record is not vulnerable to currently known attacks.

TLS also uses HMAC in other situations though, and those may well be vulnerable to collisions.
In particular, the Finished message in TLS 1.1 is not a strong MAC because it first hashes
the transcript before applying the HMAC. Similarly, the use of truncated HMACs in Finished
breaks tls-unique and weakens the renegotiation indication countermeasure.

Generally, HMAC uses as a MAC is ok, but when used as a hash function is as vulnerable
to collisions as the underlying hash function.

Coming back to digital signatures, all uses of weak hash functions are essentially broken. 
The attacks on certificates were well known, and SLOTH shows that other uses
of digital signatures in many mainstream protocols also require collision resistance.

Best,
Karthik


> 
> Compare the Security Considerations of rfc2104 for the (in)significance
> of current collision attacks for HMAC.
> 
> https://tools.ietf.org/html/rfc2104#section-6
> 
> 
> -Martin
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls