Re: [TLS] Confirming consensus about one

Nelson B Bolyard <nelson@bolyard.me> Wed, 27 January 2010 16:55 UTC

Return-Path: <nelson@bolyard.me>
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 65AA43A6961 for <tls@core3.amsl.com>; Wed, 27 Jan 2010 08:55:32 -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=[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 nURY+5JpV8RC for <tls@core3.amsl.com>; Wed, 27 Jan 2010 08:55:32 -0800 (PST)
Received: from smtpauth18.prod.mesa1.secureserver.net (smtpauth18.prod.mesa1.secureserver.net [64.202.165.31]) by core3.amsl.com (Postfix) with SMTP id 35C633A683E for <tls@ietf.org>; Wed, 27 Jan 2010 08:55:32 -0800 (PST)
Received: (qmail 25455 invoked from network); 27 Jan 2010 16:49:07 -0000
Received: from unknown (24.5.142.42) by smtpauth18.prod.mesa1.secureserver.net (64.202.165.31) with ESMTP; 27 Jan 2010 16:49:07 -0000
Message-ID: <4B606E82.8080905@bolyard.me>
Date: Wed, 27 Jan 2010 08:49:06 -0800
From: Nelson B Bolyard <nelson@bolyard.me>
Organization: Network Security Services
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1b1pre) Gecko/20081004 NOT Firefox/2.0 SeaMonkey/2.0a2pre
MIME-Version: 1.0
To: tls@ietf.org
References: <201001271537.o0RFb31s016880@fs4113.wdf.sap.corp>
In-Reply-To: <201001271537.o0RFb31s016880@fs4113.wdf.sap.corp>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org
Subject: Re: [TLS] Confirming consensus about one
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, 27 Jan 2010 16:55:32 -0000

On 2010-01-27 07:37 PST, Martin Rex wrote:
> Yoav Nir wrote:

>> Actually it's easier to hard-code the ciphersuite list on the client,
>> because it never changes with most applications. Adding logic to
>> differentiate between initial handshakes and repeated handshakes
>> complicates the code (though not by much)
> 
> It more complicated than that, because SCSV is additionally necessary
> for sensible behaviour even with -03 when doing old renegotiation
> on a connection where the initial ClientHello did not use any
> TLS extensions.

I think you meant to write "necessary to prevent vulnerable renegotiation on
a connection where the initial ClientHello did not use any TLS extensions".
 If that is what you meant, please confirm.

What you wrote sounds more like you were expecting "old renegotiation" to
succeed.  If you were indeed expecting that, then why does SCSV play any
role in that at all?