IETF Logo Mail Archive

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

Andrei Popov <Andrei.Popov@microsoft.com> Fri, 10 July 2015 17:31 UTC

Return-Path: <Andrei.Popov@microsoft.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 1EB9C1A0371 for <tls@ietfa.amsl.com>; Fri, 10 Jul 2015 10:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 XTv5Gg0AySKF for <tls@ietfa.amsl.com>; Fri, 10 Jul 2015 10:31:04 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0103.outbound.protection.outlook.com [65.55.169.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3962B1A0369 for <tls@ietf.org>; Fri, 10 Jul 2015 10:31:04 -0700 (PDT)
Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1394.namprd03.prod.outlook.com (10.163.81.140) with Microsoft SMTP Server (TLS) id 15.1.207.19; Fri, 10 Jul 2015 17:31:02 +0000
Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0207.004; Fri, 10 Jul 2015 17:31:02 +0000
From: Andrei Popov <Andrei.Popov@microsoft.com>
To: "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)
Thread-Index: AQHQuMqGail83kPeBUGeFeksHA1hqJ3QLTyAgAAI+QCAAAQ1gIAADWmAgAA2FYCAAVxcgIAAAVqAgAAEyoCAAVE1AIABlogAgAAEJoCAAAXGgIAACRQAgAADNACAAAGWgIAAA+QAgAAQkpA=
Date: Fri, 10 Jul 2015 17:31:01 +0000
Message-ID: <BLUPR03MB139645B664D7C3998B2DAA3C8C9F0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CALuAYvbteowTeyWe9VneRHgyvzTRS3LfKdorWt=jmEy2k+wNqw@mail.gmail.com> <201507101137.44703.davemgarrett@gmail.com> <20150710154912.GU28047@mournblade.imrryr.org> <201507101154.53812.davemgarrett@gmail.com> <20150710160848.GW28047@mournblade.imrryr.org>
In-Reply-To: <20150710160848.GW28047@mournblade.imrryr.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;
x-originating-ip: [2001:4898:80e8:ee31::4]
x-microsoft-exchange-diagnostics: 1; BLUPR03MB1394; 5:7q3yKniVCo88wiAToNyM30PVMDvh15hft2i2Z81+3aXz3reJuHQHmY0FkQLo7oAwA5DilrQMqPvcW0PvIX8Vh1g7mgu+lU2Neeg8jYHGHk5z0HF0fAfnZfPU1cljXDpKiG9L8TPeb8uaPEc/qeHNEA==; 24:8ZpTTFMxBdzdd6X93DGLR0HfNh7RpD+YNEQhCwY12KHu5jC0oFNjyBtKlOfBA+kNbnra2uCYsM/0z0xd5AlgmAgRpOiWUw9F+TxoicnaK/E=; 20:A+ubvqdpLZlq/1GqQQt9lP02TDrZdulXf86VDdvATUyf7q//g2Lt0E7S7dtHso+BBO5wsj9a2wFkBsbBcFK8VQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1394;
x-microsoft-antispam-prvs: <BLUPR03MB1394AB589D63ED08F6716C5F8C9F0@BLUPR03MB1394.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BLUPR03MB1394; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1394;
x-forefront-prvs: 06339BAE63
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(377454003)(51704005)(13464003)(24454002)(74316001)(2950100001)(5003600100002)(2900100001)(189998001)(102836002)(15975445007)(122556002)(40100003)(5002640100001)(86362001)(76576001)(93886004)(5001960100002)(107886002)(110136002)(54356999)(2501003)(46102003)(19580405001)(92566002)(2351001)(86612001)(5001920100001)(50986999)(76176999)(450100001)(87936001)(77156002)(77096005)(62966003)(2656002)(99286002)(33656002)(106116001)(19580395003)(3826002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1394; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2015 17:31:01.5337 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1394
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/UPNyhtNJ1WfDBrIfpeqgUtwwUzE>
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
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 17:31:06 -0000

Hi Viktor,

Quoting my previous response to this thread: 
"It is possible that we might improve the product by not complying with section 7.4.1.4.1 of RFC 5246 in a future release, but currently schannel does comply."

This thread has shown that it is hard to argue that schannel is RFC non-compliant WRT this particular problem. However, indeed it can be argued that in this case the product does not benefit from being RFC-compliant.
 
Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni
Sent: Friday, July 10, 2015 9:09 AM
To: tls@ietf.org
Subject: Re: [TLS] Deprecate SHA1 for signatures in TLS 1.3 (was Re: TLS 1.3 draft-07 sneak peek)

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.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

v2.23.0 | Report a Bug | By Email