IETF Logo Mail Archive

Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 10 July 2015 16:08 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 133FC1B2CCC for <tls@ietfa.amsl.com>; Fri, 10 Jul 2015 09:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 Z0Te3O_cN60q for <tls@ietfa.amsl.com>; Fri, 10 Jul 2015 09:08:49 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B86F91B2CBB for <tls@ietf.org>; Fri, 10 Jul 2015 09:08:49 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C421A284D69; Fri, 10 Jul 2015 16:08:48 +0000 (UTC)
Date: Fri, 10 Jul 2015 16:08:48 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150710160848.GW28047@mournblade.imrryr.org>
References: <CALuAYvbteowTeyWe9VneRHgyvzTRS3LfKdorWt=jmEy2k+wNqw@mail.gmail.com> <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <201507101154.53812.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/SiTh5cJ9bo90tUSi6MFAnyKwjRI>
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tls@ietf.org
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, 10 Jul 2015 16:08:51 -0000

On Fri, Jul 10, 2015 at 11:54:53AM -0400, Dave Garrett wrote:

> On Friday, July 10, 2015 11:49:12 am Viktor Dukhovni wrote:
> > With time we learn to ignore some elements of specifications that
> > don't make sense.  This is one such element.
> 
> Which will lead to problems like this because not everyone will agree on
> what parts to ignore. If you want it to actually work reliably, you're
> going to need to follow or amend the spec.

I am proposing that the specification bug be fixed in TLS 1.3.

Indeed specification bugs are suboptimal.  In cases such as this
one, not implementing the specification bug leads to unconditionally
improved behaviour.  In some other cases, one has no choice but to
implement the bug.

For example, Postfix ignores a bug in RFC 5321 that suggests treating
a 552 response to "RCPT TO" as though it were a 452 response.
Following this causes more problems in practice than the mostly
theoretical problem it solves.

So if Andrey Poppv is still following this thread, I would like to
suggest that Schannel be revised to be more tolerant of clients
that don't offer a signature algorithm that matches the server's
chain and use the server chain anyway.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email