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, 07 July 2015 20:59 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 7F4671ACCE5 for <tls@ietfa.amsl.com>; Tue, 7 Jul 2015 13:59:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 LWhss17mn5jG for <tls@ietfa.amsl.com>; Tue, 7 Jul 2015 13:59:00 -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 28D911ACC8A for <tls@ietf.org>; Tue, 7 Jul 2015 13:58:59 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 0A0E4284D68; Tue, 7 Jul 2015 20:58:59 +0000 (UTC)
Date: Tue, 07 Jul 2015 20:58:59 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150707205858.GH21534@mournblade.imrryr.org>
References: <CABcZeBOWK_WnHAefsZUBr4UyEkyiZqi1mhoZH8ZeGFftdOqTTw@mail.gmail.com> <CABcZeBMPsopxV=mu+MJAwJC6w=iuytA3ueyXKpg1QFdV=JWirw@mail.gmail.com> <201507071242.23235.davemgarrett@gmail.com> <201507071257.26088.davemgarrett@gmail.com> <CABcZeBNxW6jaf=HZFvm56K5pKeLD4GyNXOimUHUCt34r_76Vzw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBNxW6jaf=HZFvm56K5pKeLD4GyNXOimUHUCt34r_76Vzw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/rQq_LJVAw3ZU7RYzGbHay2iQcCY>
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, 07 Jul 2015 20:59:01 -0000

On Tue, Jul 07, 2015 at 10:45:25AM -0700, Eric Rescorla wrote:

> So if you can't express SHA1 in signature_algorithms, then the server can't
> send you a certificate signed with SHA-1.

This is a very unfamiliar use of the word "can't".  In practice
most servers will send whatever (fixed) certificate chain they're
configured with, no matter the content of the signature_algorithm
extension.  Servers that possess otherwise equivalent chains that
differ only in the signature algorithm are rather rare beasts AFAIK.

Which SSL libraries allow server administrators to configure multiple
chains based on the signature algorithm?

Which SSL libraries allow clients to configure multiple chains and
present the appropriate one to the server based on signature
algorithm?

My impression is that chain selection based on the extension is
largely wishful thinking.

-- 
	Viktor.