Re: [TLS] Chatter on consensus

Martin Rex <mrex@sap.com> Thu, 28 January 2010 20:52 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 9AED428C101 for <tls@core3.amsl.com>; Thu, 28 Jan 2010 12:52:00 -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 RGtS-goV+0uH for <tls@core3.amsl.com>; Thu, 28 Jan 2010 12:51:59 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 6D57D3A682E for <tls@ietf.org>; Thu, 28 Jan 2010 12:51:59 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o0SKq5Zf010694 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 28 Jan 2010 21:52:05 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001282052.o0SKq4lg008352@fs4113.wdf.sap.corp>
To: nmav@gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 28 Jan 2010 21:52:04 +0100 (MET)
In-Reply-To: <4B61B8E1.9060801@gnutls.org> from "Nikos Mavrogiannopoulos" at Jan 28, 10 05:18:41 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: 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
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: Thu, 28 Jan 2010 20:52:00 -0000

Nikos Mavrogiannopoulos wrote:
> 
> 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.

I'm sorry, I fail to understand.

Look at the -03 document (server receiving ClientHello), and what
the removal of the rfc-2119 incompliant imperative in -03 will
mean for the text and what it will mean for the TLS implementation
(I'm leaving out the obviated tests in the test framework for simplicity).

You can look at it form every perspective, it's simple,
it's an obvious improvement, and will make it rfc-2119 compliant.


3.7. Server Behavior: Secure Renegotiation


   This text applies if the connection's "secure_renegotiation" flag is
   set to TRUE (if it is set to FALSE, see Section 4.4).

-  o  When ClientHello is received, the server MUST verify that it does
-     not contain the TLS_RENEGO_PROTECTION_REQUEST SCSV.  If the SCSV
-     is present, the server MUST abort the handshake.
   o  The server MUST verify that the "renegotiation_info" extension is
      present; if it is not, the server MUST abort the handshake.
   o  The server MUST verify that the value of the
      "renegotiated_connection" field is equal to the saved
      client_verify_data value; if it is not, the server MUST abort the
      handshake.


In Meta-Code this might look like this:

   extensions = GetHelloExtensions(hmsg, ptr, hmsg_len)

   if ( NULL!=cur_session->cipher_state ) {
      /* this is a renegotiation */
      if ( (secure_renegotiation) ) {
         /* this ought to be a secure renegotiation */

-        if ( scsv_flag ) {
-             send_alert( cur_session, AL_FATAL, AL_HANDSHAKE_FAILURE );
-             rc = ERR_POSSIBLE_RENEGO_ATTACK;
-             goto error_cleanup;
-        }
-
         ri_contents = get_RI_contents(extensions);
         if ( NULL==ri_contents ) {
              send_alert( cur_session, AL_FATAL, AL_HANDSHAKE_FAILURE );
              rc = ERR_POSSIBLE_RENEGO_ATTACK;
              goto error_cleanup;
         }
         
         if ( !verify_RI_contents(cur_session,ri_contents) ) { 
              send_alert( cur_session, AL_FATAL, AL_HANDSHAKE_FAILURE );
              rc = ERR_POSSIBLE_RENEGO_ATTACK;
              goto error_cleanup;
         }
 


-Martin