IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Fri, 24 March 2017 05:23 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 4E1991243F6 for <tls@ietfa.amsl.com>; Thu, 23 Mar 2017 22:23:47 -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] autolearn=ham autolearn_force=no
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 WnI614ueLs21 for <tls@ietfa.amsl.com>; Thu, 23 Mar 2017 22:23:45 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18D7C120726 for <tls@ietf.org>; Thu, 23 Mar 2017 22:23:43 -0700 (PDT)
Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id E47467A32F1 for <tls@ietf.org>; Fri, 24 Mar 2017 05:23:42 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABkgnnVS-0vh_fPVQVnq6YxxrYNQ1=+90Ct8CmUocJf7R6k4bA@mail.gmail.com>
Date: Fri, 24 Mar 2017 01:23:41 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <7970606B-0096-475D-8842-2A14E5168413@dukhovni.org>
References: <E6C9F0E527F94F4692731382340B337846DD1B@DENBGAT9EH2MSX.ww902.siemens.net> <1490317199552.71745@cs.auckland.ac.nz> <52C6D0EF-D6AC-484A-9096-BDAE5C870F82@dukhovni.org> <CABkgnnVS-0vh_fPVQVnq6YxxrYNQ1=+90Ct8CmUocJf7R6k4bA@mail.gmail.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/GmeYTiZ2mUm2PDqqfutgJlxjpZ0>
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 05:23:47 -0000

> On Mar 24, 2017, at 1:08 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> 
>> I've never seen
>> a TLS server that has multiple chains to choose from for the same
>> server identity.

Both chains of course use SHA256.

Sorry I meant to say multiple digest algorithms for otherwise
identical chains (same public key algorithm and server name).

Even in the SMTP space some servers have both RSA and ECDSA certs.
When that's the case, cipher negotiation ensures that the selected
EE certificate's public key algorithm is mutually supported.

There's still little need to pay attention to the client's signature
algorithms in choosing the EE-certificate and associated chain.

-- 
-- 
	Viktor.

v2.23.0 | Report a Bug | By Email