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:09 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 6D1941B2C49 for <tls@ietfa.amsl.com>; Tue, 14 Jul 2015 13:09:04 -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 5sHIWLalXLLP for <tls@ietfa.amsl.com>; Tue, 14 Jul 2015 13:09:03 -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 C0EE51B2C4E for <tls@ietf.org>; Tue, 14 Jul 2015 13:08:40 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 07004284D74; Tue, 14 Jul 2015 20:08:40 +0000 (UTC)
Date: Tue, 14 Jul 2015 20:08:39 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150714200839.GE28047@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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <BLUPR03MB13969324E4C95B2D6DC9A7558C9B0@BLUPR03MB1396.namprd03.prod.outlook.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/n40FwBkjfRN5EUK2_C-nS8wBljs>
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:09:04 -0000

On Tue, Jul 14, 2015 at 07:30:38PM +0000, Andrei Popov wrote:

> Using anonymous cipher suites for opportunistic connections allows the
> server operator to explicitly enable anonymous connections, and it saves
> bytes on the wire.

Yes, and informs the server that the client is skipping authentication,
which is often useful information on the server end.  Is it a common
mistake to suggest that servers should disable anon_DH, that advice
is appropriate for most clients, but is mostly wrong for servers.

Servers might in some cases want to minimize what they present to
clients that connect with anon_DH ciphers, but they can't typically
do that when they preclude the negotiation of anon_DH.

> The downside is of course that the attacker can easily distinguish
> opportunistic clients from server-authenticating ones. Is this a concern
> for the opportunistic TLS community?

A minor concern, but a determined adversary has many ways to figure
out which client/server pairs don't involved server certificate
checks.

-- 
	Viktor.