Re: [TLS] permitted client behaviour when rejecting renegotiation

Nikos Mavrogiannopoulos <nmav@gnutls.org> Wed, 20 January 2010 17:43 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 681673A6932 for <tls@core3.amsl.com>; Wed, 20 Jan 2010 09:43:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 2mkHtUgKvZPv for <tls@core3.amsl.com>; Wed, 20 Jan 2010 09:43:29 -0800 (PST)
Received: from mail-ew0-f209.google.com (mail-ew0-f209.google.com [209.85.219.209]) by core3.amsl.com (Postfix) with ESMTP id 42F083A6895 for <tls@ietf.org>; Wed, 20 Jan 2010 09:43:29 -0800 (PST)
Received: by ewy1 with SMTP id 1so3239496ewy.28 for <tls@ietf.org>; Wed, 20 Jan 2010 09:43:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=hdYn6srQxPLj8pwPMeVgEXdZT+SMrg0z5nq1OVCIbhM=; b=N87C4hx5C8gJfb/vmnXFTzPlZqyQeFvv1ZdM2bapKkBvqL9zHxLduSe3FrMh8qKQpV qRNillW6p7SzXpTMB8jHTRnlb2t+nVwJbZkF1cWFaSTo6tRTB1aMZqAI3KK0mAZHjtFj si6d6g3mWwD1UDu+H0OrSnGqMuvIJYZanpDNg=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=WuPg/2ZO4nSu2QAbup4UdMK7dGvwFk5b6+neGdEIeCs9Yf2lFswqzHe+/g36GLSA/q HDWx0Z9ufSg/zTSl4k6Xkx23aH1K/honK1lRSUjGaJfd0qkeNyWgNeCZs8Ru/56Umlm9 jgEhcVhDp1Kg1JTI8eEngNqVGkyc2zIiEYkjY=
Received: by 10.213.39.203 with SMTP id h11mr1141894ebe.0.1264009401999; Wed, 20 Jan 2010 09:43:21 -0800 (PST)
Received: from ?10.100.2.14? (78-23-67-218.access.telenet.be [78.23.67.218]) by mx.google.com with ESMTPS id 16sm90973ewy.2.2010.01.20.09.43.20 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Jan 2010 09:43:20 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4B5740B7.4010805@gnutls.org>
Date: Wed, 20 Jan 2010 18:43:19 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: mrex@sap.com
References: <201001201658.o0KGwPU3022827@fs4113.wdf.sap.corp>
In-Reply-To: <201001201658.o0KGwPU3022827@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.95.7
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
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
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 17:43:30 -0000

Martin Rex wrote:

>> 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?

Indeed, and this is intentional. I decided to error on any received
application data, because the only use case of renegotiation I had so
far seen was the client authentication upgrade. In that case I had no
easy way to distinguish data received on the previous session and
"client authenticated" data received on the session after renegotiation.

> 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.

Then you have the issue to distinguish data on the session "before" and
the session "after" which is doable but not trivial (and probably
depends on the application layer to interpret this information as well).

> 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.

My limited experience with renegotiation shows that it is used in
coordination with the application layer to upgrade the session with new
security parameters. This is typically done on a silent phase of the
application protocol (not during a file transfer that would require full
duplex communication). Thus my decision was to implement this use case
of renegotiation and wait for some compelling reasons (use cases) to
implement the rest, which as I mentioned is not trivial.

best regards,
Nikos