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> Sat, 11 July 2015 20:57 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 036F21ACC89 for <tls@ietfa.amsl.com>; Sat, 11 Jul 2015 13:57:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 ceafxLeBetk3 for <tls@ietfa.amsl.com>; Sat, 11 Jul 2015 13:57:55 -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 7163C1ACC88 for <tls@ietf.org>; Sat, 11 Jul 2015 13:57:55 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C8EFB284D6A; Sat, 11 Jul 2015 20:57:54 +0000 (UTC)
Date: Sat, 11 Jul 2015 20:57:54 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150711205754.GX28047@mournblade.imrryr.org>
References: <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> <20150710160848.GW28047@mournblade.imrryr.org> <BLUPR03MB139645B664D7C3998B2DAA3C8C9F0@BLUPR03MB1396.namprd03.prod.outlook.com> <CABcZeBNs9+h9UWfu=eDC3JBQ1ULCcuBSOK8B9JdDsiX-Ne5g2g@mail.gmail.com> <20150711134516.GA6970@LK-Perkele-VII> <CABcZeBO2k230mP+qpP+Mfr3ee9tsvWe6BOcAgCtYxj3=PzOZPg@mail.gmail.com> <20150711151729.GO28047@mournblade.imrryr.org> <CABcZeBNfKioehp9FKjG8DaATn=dt5Fr==j=KGnSEWwCYibVeJg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBNfKioehp9FKjG8DaATn=dt5Fr==j=KGnSEWwCYibVeJg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Q_b5Tm-rb1ojKWFj9OCy_XfLQGI>
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: Sat, 11 Jul 2015 20:57:57 -0000

On Sat, Jul 11, 2015 at 04:51:53PM -0400, Eric Rescorla wrote:

> > Every time with Schannel, Exchange SMTP servers, and opportunistic
> > TLS SMTP clients
> 
> 
> Well, I assume you mean every time you have a pair with the right
> properties.
> But my question is how often that happens on the live Internet.

Well, the client would have to not offer SHA256, most do.  Schannel
issues with SMTP tend to be mostly in other corners of the spec.

For example, Schannel opportunistic clients hang-up when the server
certificate is "expired", even when they don't otherwise authenticate
the certificate, and accept self-signed  or wrong server name, ...
That is also pointlessly strict.

The breakage in this thread would require a client that offers
TLSv1.2, but not SHA256, and those are at present rare.  That
does not mean that the specification should stay wrong.

-- 
	Viktor.