Re: [TLS] Server Signature Algorithms

Martin Rex <Martin.Rex@sap.com> Mon, 02 November 2009 16:56 UTC

Return-Path: <Martin.Rex@sap.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 A2B8328C192 for <tls@core3.amsl.com>; Mon, 2 Nov 2009 08:56:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.189
X-Spam-Level:
X-Spam-Status: No, score=-6.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 dfScEZxOwYQw for <tls@core3.amsl.com>; Mon, 2 Nov 2009 08:56:23 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 9400228C156 for <tls@ietf.org>; Mon, 2 Nov 2009 08:56:23 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nA2GubhT002498 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Nov 2009 17:56:37 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200911021656.nA2Guabb006112@fs4113.wdf.sap.corp>
To: mickgray@au1.ibm.com (Michael Gray)
Date: Mon, 2 Nov 2009 17:56:36 +0100 (MET)
In-Reply-To: <OFCFFB440A.DEB1CEA7-ON4A257661.007208C6-4A257661.007271E8@au1.ibm.com> from "Michael Gray" at Nov 2, 9 06:50:02 am
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] Server Signature Algorithms
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Mon, 02 Nov 2009 16:56:24 -0000

Michael Gray wrote:
> 
> 
> "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”.

That isn't strict, that is anal.

It would safe to entirely ignore an extension that should not be present,
and this is what the general rule _implies_:

   "Be liberal in what you accept, be conservative in what you send out."


-Martin