Re: [TLS] SCSV vs RI when both specified. Was: Updated draft

Marsh Ray <marsh@extendedsubset.com> Tue, 12 January 2010 19:55 UTC

Return-Path: <marsh@extendedsubset.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 BBAAE3A683B for <tls@core3.amsl.com>; Tue, 12 Jan 2010 11:55:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.556
X-Spam-Level:
X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 xQhpy5DaY9BB for <tls@core3.amsl.com>; Tue, 12 Jan 2010 11:55:27 -0800 (PST)
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id C8E5E3A6836 for <tls@ietf.org>; Tue, 12 Jan 2010 11:55:27 -0800 (PST)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1NUmpo-0004Yy-WB; Tue, 12 Jan 2010 19:55:25 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 2B7176076; Tue, 12 Jan 2010 19:55:22 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX18X/G5etYygPApiIoHQe2fEHPVacXwZYCc=
Message-ID: <4B4CD3AB.1010102@extendedsubset.com>
Date: Tue, 12 Jan 2010 13:55:23 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <201001121939.o0CJdFsb018472@fs4113.wdf.sap.corp>
In-Reply-To: <201001121939.o0CJdFsb018472@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: DPKemp@missi.ncsc.mil, tls@ietf.org
Subject: Re: [TLS] SCSV vs RI when both specified. Was: Updated draft
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: Tue, 12 Jan 2010 19:55:28 -0000

Martin Rex wrote:
> 
> There is a document, approved by the IESG, where both of you are
> listed as document co-authors, and it says this:
> 
> http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03#section-4.3
> 
> 
> 4.3. Server Considerations
> 
> If the client does not offer the "renegotiation_info" extension or 
> the TLS_RENEGO_PROTECTION_REQUEST SCSV then this indicates that the 
> client does not support secure renegotiation.  However, because the 
> above attack looks like two handshakes to the server, the server can 
> safely continue the connection as long as it does not allow the 
> client to renegotiate.
> 
> I'm fine with that "the server can safely continue the connection as
> long as it does not allow the client to renegotiate."

I'm not, and I argued against the inclusion of that language repeatedly.

The explanation I was given, IIRC, was that it was just referring to
"the above attack" which was the one simplest case to explain. It was
not supposed to be exhaustive of all attacks.

I firmly believe that the language "the server can safely continue the
connection as long as it does not allow the client to renegotiate" is in
error.

It was not worth continuing to argue about if it delays the
implementation of the fix (which is the same in any case).

> I don't want to continue discussing this issue.

Agreed.

I'll just have to make my point with working exploit code.

- Marsh