Re: [TLS] Consistency for Signature Algorithms?

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 24 July 2017 16:11 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 04255131EA0 for <tls@ietfa.amsl.com>; Mon, 24 Jul 2017 09:11:18 -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 B1-p5aroPIjg for <tls@ietfa.amsl.com>; Mon, 24 Jul 2017 09:11:16 -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 0EB9E131E9C for <tls@ietf.org>; Mon, 24 Jul 2017 09:11:15 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 38D847A3310; Mon, 24 Jul 2017 16:11:15 +0000 (UTC)
Date: Mon, 24 Jul 2017 16:11:15 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20170724161114.GD8146@mournblade.imrryr.org>
Reply-To: tls@ietf.org
References: <3586282.tDsyLpRkWM@pintsize.usersys.redhat.com> <2a648a63-8299-1a9c-776e-f5d043371055@akamai.com> <3673860.07CCjCncdc@pintsize.usersys.redhat.com> <6f6bf32f-5c73-9213-969a-2fdf1a4c48a2@akamai.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6f6bf32f-5c73-9213-969a-2fdf1a4c48a2@akamai.com>
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/27UjrLonqFp8urv9mFuHKeegFRQ>
Subject: Re: [TLS] Consistency for Signature Algorithms?
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: Mon, 24 Jul 2017 16:11:18 -0000

On Fri, Jul 21, 2017 at 02:37:42PM -0500, Benjamin Kaduk wrote:

> I'm afraid I don't understand this remark.  There is the caveat to which
> Ilari alludes, that the server can send whatever chain it has, if the
> server can't send a chain that complies with the client's
> signature_algorithms.

"Send whatever it has" is the expected behaviour in the vast majority
of cases, i.e., for servers with just one certificate chain.  I sure
hope that server implementation that abort instead of sending some
chain will be rare.

It is indeed a nuisance that even with curves for key agreement
split off into the separate "groups" extension, the "signature
algorithms" extension is still overloaded to serve two rather
different purposes:

    1.  Negotiate algorithms suitable for signing TLS handshake
	messages.

    2.  Signal support for X.509 signature algorithms.

Using the same extension for both was perhaps a mistake.  As pointed
out in this thread,  X.509 admits more combinations for "2" than
TLS 1.3 does for "1".  Consequently TLS 1.3 servers with multiple
chains to choose from might employ suboptimal algorithms in order
to match the client's supported signature algorithm extension, even
though a better choice is available, but was not or cannot be
signalled by the client.

-- 
	Viktor.