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> Tue, 14 July 2015 20:12 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 7CFC51B2BF5 for <tls@ietfa.amsl.com>; Tue, 14 Jul 2015 13:12:26 -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 6XJ24Up3xEGp for <tls@ietfa.amsl.com>; Tue, 14 Jul 2015 13:12:25 -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 939021B2BC8 for <tls@ietf.org>; Tue, 14 Jul 2015 13:11:58 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BFC62284D74; Tue, 14 Jul 2015 20:11:57 +0000 (UTC)
Date: Tue, 14 Jul 2015 20:11:57 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150714201157.GF28047@mournblade.imrryr.org>
References: <20150714024710.GR28047@mournblade.imrryr.org> <20150714134612.F2DFF1A1DE@ld9781.wdf.sap.corp> <20150714191613.GC28047@mournblade.imrryr.org> <BLUPR03MB13969324E4C95B2D6DC9A7558C9B0@BLUPR03MB1396.namprd03.prod.outlook.com> <CABkgnnUcte-k5rYX9yz_HOeVNCBd0cHxD6+r2nbeLqsTrdniHA@mail.gmail.com> <BLUPR03MB1396E9FC7FEB4AC9FB8BFBD28C9B0@BLUPR03MB1396.namprd03.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BLUPR03MB1396E9FC7FEB4AC9FB8BFBD28C9B0@BLUPR03MB1396.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Kfx3ZQ0g6SNnn2_s6YpMpim3TOw>
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: Tue, 14 Jul 2015 20:12:26 -0000

On Tue, Jul 14, 2015 at 08:06:19PM +0000, Andrei Popov wrote:

> If opportunistic TLS handshakes need to be indistinguishable from
> server-authenticated TLS handshakes, then perhaps opportunistic clients
> have no choice but to send the signature_algorithms extension (when offering
> TLS1.2). The absence of signature_algorithms in a TLS 1.2 ClientHello can
> be used as a signal by the MITM.

Nobody is suggesting that opportunistic clients employ the extension
in question differently from other clients.  The proposal under
discussion is about how servers respond when their certificate
chain is not unequivocally compatible.

Correct server behaviour is to return some sort of chain, and let
the client decide.

TLS used by opportunistic TLS clients, largely looks the same as
TLS used by other clients, except that anon_DH may be offered,
which has little bearing on the signature algorithms extension.

-- 
	Viktor.