Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego

Michael D'Errico <mike-list@pobox.com> Fri, 13 November 2009 16:09 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 54E8F3A67B0 for <tls@core3.amsl.com>; Fri, 13 Nov 2009 08:09:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.577
X-Spam-Level:
X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, 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 yb79xOTXb4y5 for <tls@core3.amsl.com>; Fri, 13 Nov 2009 08:09:24 -0800 (PST)
Received: from sasl.smtp.pobox.com (a-pb-sasl-quonix.pobox.com [208.72.237.25]) by core3.amsl.com (Postfix) with ESMTP id 5C58C3A67A5 for <tls@ietf.org>; Fri, 13 Nov 2009 08:09:23 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D440E7FB17 for <tls@ietf.org>; Fri, 13 Nov 2009 11:09:52 -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=UG0ADfV8ty9L JoGUo7g7+rd9/VA=; b=rMpQGzSw6c8HEO9oKi/chreZCFnJT02wDCQiXMuqIQvo 0FasthxzstdfM5tN67hEyyokez0tlUtjuuPda1OO8FGyGlCCK2/vZQnr8I/vysep f0CiXcloM8cIps1/Vnqb3IIxPuh+QEWffnU/HzhKCmQnqhzLZKVqibqp6lNONKc=
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=uKpWgj glZpdtTldPkDe33Aeqgdsgk+DOp1rDhoXhKWEouxHDJKOpxvfLrEXlShKJpb2wRn 5SgUOd9WyWYLWNUWeYXy3O92uPfEP3gazV41KadB4F7CbVz+B/nZyG1vrISfX75i /KlK/CDInqiPOy81WqRvY3brGWNwjd2HJ/BlA=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id D0D2D7FB16 for <tls@ietf.org>; Fri, 13 Nov 2009 11:09:52 -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-quonix.pobox.com (Postfix) with ESMTPSA id 810AB7FB15 for <tls@ietf.org>; Fri, 13 Nov 2009 11:09:52 -0500 (EST)
Message-ID: <4AFD850C.7010704@pobox.com>
Date: Fri, 13 Nov 2009 08:10:52 -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: <200911092035.nA9KZviE026489@fs4113.wdf.sap.corp> <4AF8EF8F.3090100@jacaranda.org> <4AF8F7B4.7020101@pobox.com> <4AF8FDBD.4080003@jacaranda.org> <4AF9070E.4050305@jacaranda.org> <4AF99E04.3060604@pobox.com> <20091112055910.58D2369EF16@kilo.networkresonance.com> <4AFC46D8.9050905@pobox.com> <20091113060004.55DC569F31E@kilo.networkresonance.com>
In-Reply-To: <20091113060004.55DC569F31E@kilo.networkresonance.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: FA136590-D06E-11DE-A2DE-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Subject: Re: [TLS] assert TLSext in renego-ServerHello instead of disable renego
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: Fri, 13 Nov 2009 16:09:25 -0000

>> My point was that if the server *is* upgraded and the client does not
>> send the extension on its initial handshake, it is taking an unnecessary
>> risk.
> 
> The issue isn't whether the client sends it. Of course the client
> sends it. It's whether the client aborts the connection of the server
> doesn't return it.

I'm in agreement with you that the client should send the extension.  But
there have been messages suggesting that a client doesn't need to send it
on its initial connection, only when renegotiating.  I've been trying to
convince them that the client must send it especially in its first handshake
in order to avoid being attacked.

Mike