[TLS] signature-algorithms extension in ServerHello

Xuelei Fan <xuelei.fan@oracle.com> Thu, 30 September 2010 02:25 UTC

Return-Path: <xuelei.fan@oracle.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 730503A6BC2 for <tls@core3.amsl.com>; Wed, 29 Sep 2010 19:25:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 fWbnU5oxUOXs for <tls@core3.amsl.com>; Wed, 29 Sep 2010 19:25:48 -0700 (PDT)
Received: from gmp-eb-inf-2.sun.com (gmp-eb-inf-2.sun.com [192.18.6.24]) by core3.amsl.com (Postfix) with ESMTP id 12ACE3A69EB for <tls@ietf.org>; Wed, 29 Sep 2010 19:25:46 -0700 (PDT)
Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe1.eu.sun.com [192.18.6.7] (may be forged)) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id o8U2QUtl004344 for <tls@ietf.org>; Thu, 30 Sep 2010 02:26:31 GMT
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) id <0L9J00900G2GYV00@fe-emea-09.sun.com> for tls@ietf.org; Thu, 30 Sep 2010 03:26:14 +0100 (BST)
Received: from [129.150.64.15] ([unknown] [129.150.64.15]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.04 64bit (built Jul 2 2009)) with ESMTPSA id <0L9J00H1EG3I9C60@fe-emea-09.sun.com> for tls@ietf.org; Thu, 30 Sep 2010 03:26:13 +0100 (BST)
Date: Thu, 30 Sep 2010 10:25:58 +0800
From: Xuelei Fan <xuelei.fan@oracle.com>
Sender: Xuelei.Fan@Sun.COM
To: tls@ietf.org
Message-id: <4CA3F536.5030307@oracle.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
Subject: [TLS] signature-algorithms extension in ServerHello
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: Thu, 30 Sep 2010 02:25:48 -0000

 Hi,

In the end of section 7.4.1.4.1, RFC5246 (TLS 1.2), it says that
    Servers MUST NOT send this extension. ...
    When performing session resumption, this extension is not included
in Server Hello, and the server ignores the extension in Client Hello
(if present).

"this extension is not included in Server Hello" is a little confusing
to me. No matter full handshake or session resumption, this extension
MUST NOT be included in the ServerHello message, right?

And I don't think it is a type of "this extension is not included in
Client Hello", because when requesting a session resumption, a client
normally cannot expect whether the server will do a full handshake or a
abbreviated handshake, so the client need to always include this
extension in ClientHello for the preference signature algorithms.
Otherwise, the server may be able  to response with a full handshake and
use not-that-strong algorithms, such as (sha1, rsa), while the client
may only want to SHA-2 hash functions.

Thanks,
Xuelei Fan