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

Watson Ladd <watsonbladd@gmail.com> Tue, 12 January 2016 00:33 UTC

Return-Path: <watsonbladd@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 79EAA1ACC72 for <tls@ietfa.amsl.com>; Mon, 11 Jan 2016 16:33:00 -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 KKVgeQyyXOKI for <tls@ietfa.amsl.com>; Mon, 11 Jan 2016 16:32:59 -0800 (PST)
Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (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 DCE731AC3CF for <tls@ietf.org>; Mon, 11 Jan 2016 16:32:58 -0800 (PST)
Received: by mail-yk0-x22b.google.com with SMTP id a85so373362313ykb.1 for <tls@ietf.org>; Mon, 11 Jan 2016 16:32:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ljRJ5UUJulzxoufy5gsAzyvi1XAIfi959w7X/1eeUV8=; b=iIXo5qv8J78SMpcc0ZAtvt+XjXzjBdgg994ZAjX/0E9WIllMRPuqtkvU4i/btrNTxX iKLP35hyKhY72DOigFtkf8ijXyyf0XXGTkDfWQaB7EZfiYieqAUJLgtaJ6PMqDehRyEb Rp3xJFCP5Z8DC53/OAxKqn9TVcYo0u41mlDcvnsYY51bTV/NLLV1yx2Bl78s3XPfn3Ah WnrJJv6n/+Dk9NcKjVHm1SkajPxpLHZDIduoLiNr0VLgFHA/uW1Jz/B1z6Jq53gZMi7R 3hIzJziN7SrZHXgukuHfckMR68sseIGFZCQ1y1NytLKz5cdQlXy0SZ9ANImvGHUj+Hrx 1xCg==
MIME-Version: 1.0
X-Received: by 10.129.57.135 with SMTP id g129mr92630932ywa.244.1452558778202; Mon, 11 Jan 2016 16:32:58 -0800 (PST)
Received: by 10.13.216.150 with HTTP; Mon, 11 Jan 2016 16:32:58 -0800 (PST)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz>
References: <20160111183017.GA12243@roeckx.be> <9A043F3CF02CD34C8E74AC1594475C73F4BC5FC6@uxcn10-5.UoA.auckland.ac.nz>
Date: Mon, 11 Jan 2016 16:32:58 -0800
Message-ID: <CACsn0cmSBB3TDA-LCDCusQA9KWDzwAoJWrZ=67FquW968vrkBA@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset=UTF-8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/3mOYNbEfDqFAAJHS2GVf6VQ2fVs>
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 00:33:00 -0000

On Mon, Jan 11, 2016 at 3:09 PM, Peter Gutmann
<pgut001@cs.auckland.ac.nz>; wrote:
> 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.

Do the RFCs require the relevant checks or not? And given that
implementations frequently get these sorts of things wrong, how do we
make the standard robust against it?

>
>>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".

And if you actually read beyond the abstract, you would see that he
never considers the straight up concatenation of MD5 and SHA1 which is
indeed vulnerable, exactly matching the attacks he develops.
>
> 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.

That's because real cryptographers understand that this is only 64
times better then SHA1, and so don't bother to mention it.
>
> Peter.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.