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.