Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2

Peter Gutmann <pgut001@cs.auckland.ac.nz> Fri, 24 March 2017 01:11 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879DE1276AF for <tls@ietfa.amsl.com>; Thu, 23 Mar 2017 18:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz
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 SD90BtOBKZgB for <tls@ietfa.amsl.com>; Thu, 23 Mar 2017 18:11:55 -0700 (PDT)
Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D044129B10 for <tls@ietf.org>; Thu, 23 Mar 2017 18:11:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1490317914; x=1521853914; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=qDm+mVII48frxED6G3fPZe4hHzToBYD0c0Vn5tpaCjU=; b=HnqcCwlvclL7FMFfIAM0kag+h/Z4ts6uKN+yx0ywkYnV57Uq/Cu5JGhu sXweMOfQ+9hMu0KGggdNM4p8f+WMRoSH2KDoT3HYxXQsEQFPJ/F/601Nz TVO1Cg8bvirD8wWhlR5YMBUFEoFec/zqCeugK2uVuEvI3mxYL7QBvwP4+ Fya2g5H2fQ9vIKCPAwxc9qj2cIj4+QExgxXq7WQVmjs0UjksePLKvzYGY 6DH2NN0+onzKr7r1wmTrd2XXS50E617ClUrto57Pq07+n4Xa2N5Y42tc0 Lm+hdnEnaC0GhPxszXI2u1dgKXB63tHJssb//TzmfG7YeuhYEtYfSSXVO Q==;
X-IronPort-AV: E=Sophos;i="5.36,212,1486378800"; d="scan'208";a="145118653"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing
Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-e.UoA.auckland.ac.nz) ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 24 Mar 2017 14:11:52 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 24 Mar 2017 14:11:52 +1300
Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 24 Mar 2017 14:11:52 +1300
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: Andrei Popov <Andrei.Popov@microsoft.com>, "Fries, Steffen" <steffen.fries@siemens.com>, TLS WG <tls@ietf.org>
Thread-Topic: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2
Thread-Index: AdKj4jdTMGBzllsXQzCZ8vwWateOaP//KBSAgAAMVgCAAAPbAIAAFOEAgAFlb68=
Date: Fri, 24 Mar 2017 01:11:52 +0000
Message-ID: <1490317904391.60980@cs.auckland.ac.nz>
References: <E6C9F0E527F94F4692731382340B337846DD1B@DENBGAT9EH2MSX.ww902.siemens.net> <4DD1F233-D659-4F79-9ADA-BC31A49DA653@dukhovni.org> <CABcZeBNu_9EHKWFzWFvtcUZ5GA5SQ8DbjHqEvn4yjBLH6=yuXg@mail.gmail.com> <E6C9F0E527F94F4692731382340B337846DE14@DENBGAT9EH2MSX.ww902.siemens.net>, <DM2PR21MB009159D219B9691EF67FD5568C3F0@DM2PR21MB0091.namprd21.prod.outlook.com>
In-Reply-To: <DM2PR21MB009159D219B9691EF67FD5568C3F0@DM2PR21MB0091.namprd21.prod.outlook.com>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Z48qt63ResMZKxbt1BZZoTsn1kA>
Subject: Re: [TLS] Enforcing stronger server side signature/hash combinations in TLS 1.2
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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, 24 Mar 2017 01:11:57 -0000

Andrei Popov <Andrei.Popov@microsoft.com> writes:

>Unfortunately, in practice there are TLS 1.2 clients that support SHA256, but
>don’t advertise it via the signature algorithms extension.

It's actually pretty safe to just automatically assume SHA256 (for TLS 1.2),
regardless of what the other side advertises.  There was a survey paper
published a while back, I can't remember exactly which one, one of the many
TLS-in-the-wild ones, which showed that of the servers that supported ECC,
close to 100% did P256 + SHA256, some low single-digit figure were P521+512,
and 384 was lost in the margin of error, some fraction of a percent.  Of the
anecdotal evidence from SCADA etc which isn't publicly visible, it's about the
same, you can pretty much assume P256 + SHA256 by default.

Which is precisely why LTS specifies P256 + SHA256 as its MTI if you're doing
ECC.  To paraphrase Calvin's quote about success, "the secret to success is
changing your expectations so that they're already met".  Assume P256+SHA256
(when ECC is indicated), or just SHA256 in general for 1.2, and you won't be
disappointed.

Peter.