Re: [TLS] permitted client behaviour when rejecting renegotiation

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 21 January 2010 07:52 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 1C1CD3A69C9 for <tls@core3.amsl.com>; Wed, 20 Jan 2010 23:52:45 -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=[AWL=0.000, 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 2VVxzJBTtHSk for <tls@core3.amsl.com>; Wed, 20 Jan 2010 23:52:44 -0800 (PST)
Received: from mail-ew0-f218.google.com (mail-ew0-f218.google.com [209.85.219.218]) by core3.amsl.com (Postfix) with ESMTP id 207A33A69AE for <tls@ietf.org>; Wed, 20 Jan 2010 23:52:43 -0800 (PST)
Received: by ewy10 with SMTP id 10so605758ewy.14 for <tls@ietf.org>; Wed, 20 Jan 2010 23:52:33 -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=XPxlvy6Sm0bUFgexObRV32+Jp4FCK91P31mCzAG1ABA=; b=MQf5SREA1lKWgeGM8n11X85TC+3+Oea6zjF5wAl8FYGp85sFany3W61803aEMKsSJO aFUPwQ421XNMNeQ+UVDw2OwDGZaAQOr97Ht1ZlzyF1UJRm/fcZmwCb+UjyriGcTBTFi/ IQB5R0YRGeMPdyP5vkhUHfZ00uNgaIB3T5BRU=
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=VimvRpUxA+ykPmzyGJpjxOYvRtpagilIvUKpQ9aIeNZJnI6H2HIbAm81U888K6PSMQ n6qkxZgqkGTJaDBaSCr027d7jC3CxYvo7XPRkfYN+GUhUlAij5z3l5t+ZQq6gR45plH6 oakoFuBbr4b+l4Zr3fwjJr0otOMgjlwRmxcpM=
Received: by 10.213.61.9 with SMTP id r9mr1062975ebh.8.1264060353403; Wed, 20 Jan 2010 23:52:33 -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 16sm621043ewy.6.2010.01.20.23.52.31 (version=SSLv3 cipher=RC4-MD5); Wed, 20 Jan 2010 23:52:32 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4B5807BE.6010206@gnutls.org>
Date: Thu, 21 Jan 2010 08:52:30 +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: <201001202312.o0KNC2kr016804@fs4113.wdf.sap.corp>
In-Reply-To: <201001202312.o0KNC2kr016804@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: Thu, 21 Jan 2010 07:52:45 -0000

Martin Rex wrote:

> I should clarify this:  Prohibiting app data exchange _during_ a
> renegotiation handshake is something that I advocated for myself
> (and would likely implement myself if I would implement TLS), see

Ah ok I got the point. Applications that use gnutls can in the time
frame between renegotiation request and handshake start to check and
read pending application data. However this is not done implicitly by
the handshake procedure, that will error if it encounters application data.

> http://www.ietf.org/mail-archive/web/tls/current/msg04091.html
> 
> But given the full-duplex nature of the TLS exchanges before
> and after renegotiation, I would cut the "renegotiation handshake"
> differently, and _not_ consider a HelloRequest message to be part
> of that handshake.  Because of the full-duplex nature, the handshake
> is not guaranteed to be started synchronously on both directions
> of the communication.  The TLS handshake itself is half-duplex
> by nature (which might be the reason why the SSL spec defined the
> interleaving of renegotiation handshake and application data
> in the first place).

Indeed, but there is always the issue of how many record packets to
accept before starting the handshake. Is the client allowed to start the
handshake 2 minutes later or after 2mb of transferred data? Currently I
left this to the application developer.

regards,
Nikos