[TLS] permitted client behaviour when rejecting renegotiation

Martin Rex <mrex@sap.com> Wed, 20 January 2010 01:51 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 82E6F3A689A for <tls@core3.amsl.com>; Tue, 19 Jan 2010 17:51:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.117
X-Spam-Status: No, score=-10.117 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id s9y8xY-zAgTq for <tls@core3.amsl.com>; Tue, 19 Jan 2010 17:51:11 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de []) by core3.amsl.com (Postfix) with ESMTP id 592903A685F for <tls@ietf.org>; Tue, 19 Jan 2010 17:51:11 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0K1p6WB000602 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Wed, 20 Jan 2010 02:51:06 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001200151.o0K1p5UI024712@fs4113.wdf.sap.corp>
To: tls@ietf.org
Date: Wed, 20 Jan 2010 02:51:05 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Subject: [TLS] permitted client behaviour when rejecting renegotiation
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: Wed, 20 Jan 2010 01:51:12 -0000

Considering the guidance in draft-ietf-tls-renegotiation-03.txt
and the specification of HelloRequest starting with rfc-2246 (TLSv1.0)

I'm a little confused about a sensible client behaviour.

TLSv1.0 and newer say this:

   Meaning of this message:
       Hello request is a simple notification that the client should
       begin the negotiation process anew by sending a client hello
       message when convenient. This message will be ignored by the
       client if the client is currently negotiating a session.
       message may be ignored by the client if it does not wish to
       renegotiate a session, or the client may, if it wishes, respond
       with a no_renegotiation alert.

SSLv3 does not have that _general_ permission to ignore this handshake

If a client wants to abort the handshake (for whatever reason) it
should IMHO send a fatal "handshake_failure" alert *WITHOUT* a
prior warning "no_renegotiation" alert.

My impression from my testing with openssl-0.9.8l was that it may have
a server-side problem with a client ignoring HelloRequest.

Question to implementors: what will your TLS servers do when a client
simply ignores HelloRequest--a behaviour that has been allowed by all
existing TLS specs for 10 years?