Re: [TLS] Chatter on consensus

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 28 January 2010 16:18 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 5B9763A6960 for <tls@core3.amsl.com>; Thu, 28 Jan 2010 08:18: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 UUElocHI7eiH for <tls@core3.amsl.com>; Thu, 28 Jan 2010 08:18:31 -0800 (PST)
Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 3F5D93A6837 for <tls@ietf.org>; Thu, 28 Jan 2010 08:18:31 -0800 (PST)
Received: by ey-out-2122.google.com with SMTP id 22so235591eye.51 for <tls@ietf.org>; Thu, 28 Jan 2010 08:18:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=ElcITcOYVJBhZLrYuE/3h7TNbR3btymr/thlAICcS5w=; b=FEhmT5Uo0FUl+mzk2I9NkoFZEh77vM3wwhqaak9lYhk/66hrtALtHvCJkXcnqCWMwd 9l3tSTIYgt/ziQMfXrgBLvpCSNCjEeYIDBVwjfsxWVuj6y+2UFUzDffgfQnQLZ86Llhh C+nItVzA3eprh1c6twQMhos7wqq50xNuQD634=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; b=ge0vtiFJCtD9Y8ttLEhJScFpaP66t2IVm52HsAVt3YyMfc2cBWPEcJYOstMX7uchbC yodC9L2YrKs+kHdjwQVpfByWIvj6Smw36IVgHSdvEvI6mmGMgpft9XKsmbighfGWI44+ 6St03kgm910yvxNw7ZCo5otuuzcaNviprcmbQ=
Received: by 10.213.100.7 with SMTP id w7mr6985497ebn.23.1264695525203; Thu, 28 Jan 2010 08:18:45 -0800 (PST)
Received: from ?10.100.2.14? (78-23-67-218.access.telenet.be [78.23.67.218]) by mx.google.com with ESMTPS id 15sm729385ewy.8.2010.01.28.08.18.42 (version=SSLv3 cipher=RC4-MD5); Thu, 28 Jan 2010 08:18:43 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4B61B8E1.9060801@gnutls.org>
Date: Thu, 28 Jan 2010 17:18:41 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: mrex@sap.com
References: <201001272102.o0RL2I9x007631@fs4113.wdf.sap.corp>
In-Reply-To: <201001272102.o0RL2I9x007631@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.95.7
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "Kemp David P." <DPKemp@missi.ncsc.mil>, tls@ietf.org
Subject: Re: [TLS] Chatter on consensus
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: Thu, 28 Jan 2010 16:18:32 -0000

Martin Rex wrote:

>>> [Nikos]: I believe allowing the sending of both SCSV 
>>> and extension might harm interoperability instead.
> 
> This is a clear misunderstanding on the issue.
> 
> Secure renegotiation requires verification of the contents
> of the verify_data contained in the renegotiation_info.
> So if the presence of an empty RI or SCSV in a ClientHello
> during a handshake that is a renegotiation to the server
> confuses a server about having to match the verify_data,
> then you have much more serious issues to worry about.

You are considering only the case where the extension is non empty. On
initial connection the extension is empty, thus checking for extension
or the SCSV has equivalent results.

regards,
Nikos