Re: [TLS] permitted client behaviour when rejecting renegotiation

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

Return-Path: <mrex@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 11F5D3A68DF for <tls@core3.amsl.com>; Wed, 20 Jan 2010 08:58:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.137
X-Spam-Level:
X-Spam-Status: No, score=-10.137 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 FuFW8HoQRoFb for <tls@core3.amsl.com>; Wed, 20 Jan 2010 08:58:41 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id EEBD23A6837 for <tls@ietf.org>; Wed, 20 Jan 2010 08:58:40 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0KGwQqn015824 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jan 2010 17:58:26 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001201658.o0KGwPU3022827@fs4113.wdf.sap.corp>
To: nmav@gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 20 Jan 2010 17:58:25 +0100 (MET)
In-Reply-To: <4B572794.3000303@gnutls.org> from "Nikos Mavrogiannopoulos" at Jan 20, 10 04:56:04 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [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 16:58:42 -0000

Nikos Mavrogiannopoulos wrote:
> 
> Martin Rex wrote:
> > Considering the guidance in draft-ietf-tls-renegotiation-03.txt
> > and the specification of HelloRequest starting with rfc-2246 (TLSv1.0)
> > http://tools.ietf.org/html/rfc2246#section-7.4.1.1
> [...]
> > 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?
> 
> I always wondered how this behavior was supposed to work. For gnutls an
> error is returned if the request is ignored.  I think the use cases of
> these packets for renegotiation should be clearly defined (i.e. why send
> this packets and what should be expected from peer). I don't know how
> easy it is to implement the semantics precisely, but so far I didn't see
> any compelling reason to do so.


To me, this sounds like the server's gnuTLS switches to half-duplex
communication when it _sends_ a HelloRequest and expects the next
_received_ TLS record to carry a ClientHello handshake message
(or a warning-level no_renegotiation alert).

Can you describe/confirm the exact behaviour for gnuTLS?


>From its design, the TLS protocol is full-duplex, so such behaviour
would not be compliant to any existing SSL/TLS protocol spec.

The full-duplex requirement, which is implied by the definition
of the HelloRequest message in SSLv3 already is probably the reason
why the "may ignore" was written out for TLS:

   The hello request message may be sent by the server at any time,
   but will be ignored by the client if the handshake protocol is
   already underway.  It is a simple notification that the client
   should begin the negotiation process anew by sending a client hello
   message when convenient.

That "when convenient" accounts to the fact that the (app) client
may be writing and the TLS implementation therefore not even
looking (read) whether there might be a HelloRequest handshake
message waiting -- and continue sending application data.


-Martin