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

Martin Rex <mrex@sap.com> Tue, 12 January 2010 14:40 UTC

Return-Path: <mrex@sap.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 D5EAA3A698F for <tls@core3.amsl.com>; Tue, 12 Jan 2010 06:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 1O8q6GrEGVTf for <tls@core3.amsl.com>; Tue, 12 Jan 2010 06:40:12 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 1C5713A6971 for <tls@ietf.org>; Tue, 12 Jan 2010 06:40:11 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0CEe7AJ024406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 15:40:07 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001121440.o0CEe7k1026688@fs4113.wdf.sap.corp>
To: DPKemp@missi.ncsc.mil (Kemp David P.)
Date: Tue, 12 Jan 2010 15:40:07 +0100 (MET)
In-Reply-To: <200912301753.nBUHrRw2021772@stingray.missi.ncsc.mil> from "Kemp, David P." at Dec 30, 9 12:52:35 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: 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
Reply-To: mrex@sap.com
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 14:40:14 -0000

Kemp, David P. wrote:
> 
> Amazon and Google are free to accept SSLv2 as well as TLSv1.x-unpatched
> (minor MSbit unset) if they perceive the benefit of communicating to be
> greater than the risk of being attacked.   That has no bearing on
> whether the protocol spec for TLSv1.x-patched requires aborting
> connections with bozo endpoints, which of course it should.   Service
> providers/consumers can make their own choice of which protocol versions
> and ciphersuites to accept, with the knowledge that more restrictive
> choices will lock out some endpoints.   It has always been thus.

I don't understand what you mean.

If by "accept TLSv1.x-unpatched" you mean initial handshakes with the
installed base of SSLv3, TLSv1.0, TLSv1.1 or TLSv1.2 without the
renegotiation protection then your assertion is flawed.

There is absolutely _NO_ known security problem and no vulnerability for
a server to accept an initial handshake with the existing SSLv3, TLSv1.0,
TLSv1.1 or TLSv1.2 protocol, even when the ClientHello handshake
message does neither contain SCSV nor an empty extension RI.

The possibility for an "attack" where an old client's renegotiation
handshake is proxied into the initial handshake of a server is of
no concern to the server.  That's purely a client issue and has the
prerequisite that the client completely botches the server authentication
on the initial handshake and is equivalent in effectiveness to XSRF, XSS
and server impersonation -- something that protected TLS renegotiation
can not protect from.


-Martin