Re: [TLS] Server Signature Algorithms

Michael Gray <mickgray@au1.ibm.com> Sun, 01 November 2009 20:50 UTC

Return-Path: <mickgray@au1.ibm.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A59C63A6767 for <tls@core3.amsl.com>; Sun, 1 Nov 2009 12:50:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.579
X-Spam-Level:
X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, MIME_BASE64_BLANKS=0.041, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oRgLfljDPvLs for <tls@core3.amsl.com>; Sun, 1 Nov 2009 12:50:22 -0800 (PST)
Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com [202.81.31.142]) by core3.amsl.com (Postfix) with ESMTP id 9B96C28C11A for <tls@ietf.org>; Sun, 1 Nov 2009 12:50:09 -0800 (PST)
Received: from d23relay05.au.ibm.com (d23relay05.au.ibm.com [202.81.31.247]) by e23smtp09.au.ibm.com (8.14.3/8.13.1) with ESMTP id nA1KoRGf004936 for <tls@ietf.org>; Mon, 2 Nov 2009 07:50:27 +1100
Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.234.97]) by d23relay05.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id nA1KlQQk1613972 for <tls@ietf.org>; Mon, 2 Nov 2009 07:47:26 +1100
Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id nA1KoQnN003638 for <tls@ietf.org>; Mon, 2 Nov 2009 07:50:26 +1100
Received: from d23ml003.au.ibm.com (d23ml003.au.ibm.com [9.190.250.22]) by d23av03.au.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id nA1KoQB5003635; Mon, 2 Nov 2009 07:50:26 +1100
In-Reply-To: <4AE9F0DE.7060903@pobox.com>
To: "Michael D'Errico" <mike-list@pobox.com>
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: <OFCFFB440A.DEB1CEA7-ON4A257661.007208C6-4A257661.007271E8@au1.ibm.com>
From: Michael Gray <mickgray@au1.ibm.com>
Date: Mon, 2 Nov 2009 06:50:02 +1000
X-MIMETrack: Serialize by Router on d23ml003/23/M/IBM(Release 7.0.2FP3HF80 | July 14, 2008) at 02/11/2009 07:56:56
MIME-Version: 1.0
Content-type: text/plain; charset=UTF-8
Content-transfer-encoding: base64
Cc: tls@ietf.org
Subject: Re: [TLS] Server Signature Algorithms
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Sun, 01 Nov 2009 20:50:23 -0000

"Michael D'Errico" <mike-list@pobox.com> wrote:

> There are now at least 3 instances where a TLS client needs to know the
> server's list of supported signature algorithms:
>
>     1. to compute the signature for the CertificateVerify message
>     2. to compute the hash of the handshake messages in (1) without
>        having to hold onto all of the messages
>     3. to compute hashes for the proposed cached information extension
>
> Rather than duplicate the list for each of these and any future needs,
> it makes sense to send it once in a server hello extension.
>
> The simplest option would be to use the existing signature algorithms
> extension and make it symmetrical.  But if there is a deployed client
> out there that aborts a connection if it receives a signature algorithm
> extension, then a secondary option would be to create a new server-
> signature-algorithms extension which is identical in structure to the
> existing extension.
>
> I would add that when the server sends its list of algorithms in the
> extension, then it MUST NOT send a different list in the certificate
> request message; in fact it SHOULD send an empty list.  TLS 1.3 can
> decide whether to eliminate the list from CertificateRequest.

Currently our toolkit when operating as a client will abort the handshake
on this condition due to RFC 5246 in 7.4.1.4.1 saying: “Servers MUST NOT
send this extension”.

We could change our code to optionally (e.g. a non strict mode) accept
receiving the extension from a TLS Server as that would be IMHO relatively
harmless.  The problem I see would be if we enabled our Server side code to
optionally send this extension, that would open the door for existing TLS
Clients to abort the handshake.  We have no idea which Client (vendor) type
may be involved in a handshake and what revision of the implementation in
this area they might support i.e., there is no way for the Client to
indicate that it will tolerate the Server sending the extension.  IMHO It
is unfortunate version information is not included in each extension.  So
while I agree that this sounds a good move I would be concerned as to the
impact on system availability should any Server now be configured to start
sending this extension.  IMHO I think the horse might have already bolted
in this case :-(

Mick


> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls