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

Martin Rex <mrex@sap.com> Tue, 12 January 2010 19:39 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 204F33A6ACC for <tls@core3.amsl.com>; Tue, 12 Jan 2010 11:39:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.206
X-Spam-Level:
X-Spam-Status: No, score=-10.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 uPQBUjppU3cQ for <tls@core3.amsl.com>; Tue, 12 Jan 2010 11:39:22 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 05BAC3A68B5 for <tls@ietf.org>; Tue, 12 Jan 2010 11:39:21 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0CJdG7M013697 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Jan 2010 20:39:16 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001121939.o0CJdFsb018472@fs4113.wdf.sap.corp>
To: dispensa@phonefactor.com (Steve Dispensa)
Date: Tue, 12 Jan 2010 20:39:15 +0100 (MET)
In-Reply-To: <D0E89820-41D3-4263-9427-0FA0166F8CFC@phonefactor.com> from "Steve Dispensa" at Jan 12, 10 09:42:31 am
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: 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
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 19:39:23 -0000

Steve Dispensa wrote:
> 
> On Jan 12, 2010, at 9:17 AM, Marsh Ray wrote:
> 
> > Martin Rex wrote:
> >>
> >> 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.
> >
> > Baloney!

Steve and Marsh.

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 don't want to continue discussing this issue.

-Martin