IETF Logo Mail Archive

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

Martin Rex <mrex@sap.com> Fri, 18 December 2009 19:46 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 D89933A69D3 for <tls@core3.amsl.com>; Fri, 18 Dec 2009 11:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.197
X-Spam-Level:
X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4]
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 F9gL+P1f7iB2 for <tls@core3.amsl.com>; Fri, 18 Dec 2009 11:46:06 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id C5B603A68FA for <tls@ietf.org>; Fri, 18 Dec 2009 11:46:05 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nBIJjn6i005606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Fri, 18 Dec 2009 20:45:49 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912181945.nBIJjnT8005613@fs4113.wdf.sap.corp>
Orig-To: marsh@extendedsubset.com (Marsh Ray)
To: tls@ietf.org
Cc: tls@ietf.org
Date: Fri, 18 Dec 2009 20:44:21 +0100
In-Reply-To: <4B2BD881.1050600@extendedsubset.com> from "Marsh Ray" at Dec 18, 9 01:31:13 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Sender: mrex@sap.com
X-Scanner: Virus Scanner virwal08
X-SAP: out
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: Fri, 18 Dec 2009 19:46:06 -0000

Marsh Ray wrote:
> 
> Martin Rex wrote:
> > Marsh Ray wrote:
> >> Currently, the SCSV achieves its primary objective with a very simple
> >> definition. It has "exactly the same semantics as an empty
> >> 'renegotiation_info' extension".
> > 
> > How about
> > 
> > TLS_RENEGO_PROTECTION_REQUEST is a request from the client to the
> > server to perform a secure handshake and confirm this by sending
> > TLS extension RI in ServerHello.
> 
> But what does that mean? What is "a secure handshake" if you're not
> sending the RI extension? To the extent that this document is describing
> how to perform a secure handshake, that definition is circular.

"A secure handshake" is one where client and server will check
whether the contents of the TLS renegotiation RI match the
verify_data from the Finished messages from the enclosing TLS session
and TLS peers should abort the handshake if the conveyed information
does not match.  The presence of an empty TLS extension RI in ClientHello
is obviated by presence of SCSV in this ClientHello handshake message.


Do not try to describe scenarios.  That is completely unecessary,
very confusing and you may easily get the description of one of
the cases wrong and cause confusion among implementors.


The implementer's feedback was:
In order to implement this MUST NOT I have to add two extra conditionals
to the code, and I have to build test cases to check whether that doesn't
break anything and whether I am compliant -- but in reality these
two conditionals are completely useless, they do not add any value
to the protocol and neither to the security.


-Martin

v2.23.0 | Report a Bug | By Email