Re: [TLS] simplistic renego protection

Michael D'Errico <mike-list@pobox.com> Wed, 18 November 2009 05:42 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 1578F3A6858 for <tls@core3.amsl.com>; Tue, 17 Nov 2009 21:42:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.502
X-Spam-Level:
X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 XSLIOxpfAaAs for <tls@core3.amsl.com>; Tue, 17 Nov 2009 21:42:09 -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 04BB63A67B8 for <tls@ietf.org>; Tue, 17 Nov 2009 21:42:07 -0800 (PST)
Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id F13FB809D4 for <tls@ietf.org>; Wed, 18 Nov 2009 00:42:05 -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=rLV0tShksC0H FA6a7jKxNsBUZx8=; b=WR/O99t35wqVXhgsZfekOLqzgajEc81+ZO9yu/SjAsz2 SrwKhEDexng1WXaO/HYirqZrpVolSE6K6cSEYH2+L0UOqVGtPXlU/E0h89Jgiee5 tB5fX2zyElCWVxHI1pBSSkT7GeSRr4smIbJXdnV1ZNyJEZjDN3c1djKt3XXLiq4=
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=L2xUsY E8L1e/32GCNIj5YoNS7d6igTm54qUIQuMGiyMw6su5/G3p6Q5KvPFuI43LM4lzoP LRvmWwthwdh9XW8k6+6/WHJSSnjfjkEJTyL5Ssgd/zYjQoZrry4870UA8bOptvMC Sgb/1Rlb1OY6eQEcP36mCXjcpHwK3ooeCMA10=
Received: from a-pb-sasl-quonix. (unknown [127.0.0.1]) by a-pb-sasl-quonix.pobox.com (Postfix) with ESMTP id ECD86809D3 for <tls@ietf.org>; Wed, 18 Nov 2009 00:42:05 -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 9C3D1809D2 for <tls@ietf.org>; Wed, 18 Nov 2009 00:42:05 -0500 (EST)
Message-ID: <4B038974.9080001@pobox.com>
Date: Tue, 17 Nov 2009 21:43:16 -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: <200911161725.nAGHPWaA014181@fs4113.wdf.sap.corp> <089F31C221374096B0FE619F@446E7922C82D299DB29D899F> <4B02A084.9030903@cs.tcd.ie> <20091117175000.653E669FBC6@kilo.networkresonance.com>
In-Reply-To: <20091117175000.653E669FBC6@kilo.networkresonance.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Pobox-Relay-ID: 1AED2604-D405-11DE-AB14-9F3FEE7EF46B-38729857!a-pb-sasl-quonix.pobox.com
Subject: Re: [TLS] simplistic renego protection
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, 18 Nov 2009 05:42:10 -0000

Eric Rescorla wrote:
> At Tue, 17 Nov 2009 13:09:24 +0000,
> Stephen Farrell wrote:
>> Having watched the recent list traffic I find the above convincing.
>> I'd love to see a -01 of the above containing the changes EKR has
>> mentioned already, and then a WGLC on that.
> 
> I just submitted an -01 version of the draft. This includes the
> following changes:
> 
> 1. Clarification of the encoding of the extension per the issue
>    by Eric Young and Nelson Bolyard.
> 2. A bunch of discussion of fallback and the downgrade issue.
> 3. A SHOULD level requirement that implementations which simply
>    reject negotiation still provide an empty extension when
>    requested by the client, thus signalling that they have
>    been updated.
> 4. A new section 4.3.1 that describes a magic cipher suite
>    to be used to prevent downgrade attack on implementations
>    which fall back to no extensions on handshake failure.

You forgot to mention:

4.3.  SSLv3

    SSLv3 does not support extensions and thus it is not possible to
    securely renegotiate with SSLv3.  Deployments wishing to renegotiate
    securely will need to upgrade to at least TLS 1.0.

Is there some secret agenda to kill off SSLv3?  What is the point
of that?  SSLv3 accounts for more than one-in-five connections as
reported to this list.  There is an alternate proposal that does not
have this limitation, and is better in many other respects.  Why do
you keep pushing this one?

Mike