Re: [TLS] Comments on draft-rescorla-tls-renegotiate.txt
Michael D'Errico <mike-list@pobox.com> Sat, 07 November 2009 16:06 UTC
Return-Path: <mike-list@pobox.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 0EB693A69A3 for <tls@core3.amsl.com>; Sat, 7 Nov 2009 08:06:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.585
X-Spam-Level:
X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 5pJeXr6981Hn for <tls@core3.amsl.com>; Sat, 7 Nov 2009 08:06:42 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-sd.pobox.com [64.74.157.62]) by core3.amsl.com (Postfix) with ESMTP id E2A913A692A for <tls@ietf.org>; Sat, 7 Nov 2009 08:06:40 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 74FAB966A3 for <tls@ietf.org>; Sat, 7 Nov 2009 11:07:04 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=F2/E5isboqCG xxLUzznw7qMejZw=; b=u1jEQlgsZ/Xkmyi1Z8v8vKhQK+ljM0ReiGDhNUGaV7Hs 7+I5BnTyiZvPieFREUCDtpXJFi2BxRfqw30wlO+8KRO6T6qxOZHwTTah7FryvV5H L/XF80MR6cGz9iDb9JSEfkQRuwtTQOKu+c82k8Yc4lRwVTuFqS35D4naYj0h0wA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=SCYQbp kxsFyBHmJZK1x98+05rYkCf9tAcvK6pIItvyfR60/ZsqrpdDN6iKKkbKRVfFJdF0 2lHgQd3NDH9vstw/CLtlmEffGnClT6HVUhEsUgwQlSMqit/LxATeQ2BH79OcqTWu uV60WxMyVYHacF80PZonTNruRAt2LuY4CZ33A=
Received: from a-pb-sasl-sd.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTP id 71BDE966A2 for <tls@ietf.org>; Sat, 7 Nov 2009 11:07:04 -0500 (EST)
Received: from administrators-macbook-pro.local (unknown [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a-pb-sasl-sd.pobox.com (Postfix) with ESMTPSA id 898CC966A0 for <tls@ietf.org>; Sat, 7 Nov 2009 11:07:03 -0500 (EST)
Message-ID: <4AF59B5E.9010603@pobox.com>
Date: Sat, 07 Nov 2009 08:07:58 -0800
From: Michael D'Errico <mike-list@pobox.com>
User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812)
MIME-Version: 1.0
To: tls@ietf.org
References: <4AF5112E.2070809@jacaranda.org>
In-Reply-To: <4AF5112E.2070809@jacaranda.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 9724D75E-CBB7-11DE-AE49-D595BBB5EC2E-38729857!a-pb-sasl-sd.pobox.com
Subject: Re: [TLS] Comments on draft-rescorla-tls-renegotiate.txt
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: Sat, 07 Nov 2009 16:06:43 -0000
> Another issue is that a server that supports the extension can refuse > the renegotiation. The current draft is not clear about what the client > and server behaviour should be in that case. > > Suggestion: > > If a ClientHello that is requesting to resume a previous session > contains a Renegotiation_Info extension, and the server supports the > extension but wishes to refuse the renegotiation, it SHOULD reply > with a zero-length Renegotiation_Info. The server already has to reply with an empty Renegotiation_Info extension. That is what happens on an initial handshake even when resuming a previous session, and also for a session_ticket resume. The draft has only a single sentence discussing session resumption: The above rules apply even when TLS resumption is used. Maybe it needs to elaborate more. > If a client that is requesting to resume a session receives a > zero-length Renegotiation_Info without a no_renegotiation alert, it > MUST abort the handshake. If it receives both a zero-length > Renegotiation_Info and a no_renegotiation alert, then the fact that > the Renegotiation_Info contents do not match the previous session's > verify_data values should not be considered a reason for the client > to abort. No, session resumption is no different w.r.t. the Renegotiation_Info extension than a full handshake. The info is always empty on the first handshake for a connection, even when resuming a previous session. As a result, you do not need to store the verify_data from the finished messages in your session cache. > Note that one legitimate reason for refusing a renegotiation is that > the old session has expired, in which case the server is likely to have > forgotten the client and server verify_data values for that session. > Nevertheless it SHOULD reply with a Renegotiation_Info to indicate > that it supports the extension. The server never needs to remember the verify_data from a previous session unless it is the currently active session. When storing a session in your session cache, the verify_data can be discarded since it is not needed in the future. If that session gets resumed later, the Renegotiation_Info will be empty. Mike > For the same reason, when the server refuses a renegotiation it may > not have the ability to check that the contents of the client's > Renegotiation_Info were correct. Therefore, there should be no > requirement for the server to check the contents in that case.
- [TLS] Comments on draft-rescorla-tls-renegotiate.… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Michael D'Errico
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… David-Sarah Hopwood
- Re: [TLS] Comments on draft-rescorla-tls-renegoti… Martin Rex