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
Date: Thu, 28 Jan 2010 21:52:04 +0100
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
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- [TLS] Confirming consensus about one draft-ietf-t… Pasi.Eronen
- Re: [TLS] Confirming consensus about one draft-ie… Robert Dugal
- Re: [TLS] Confirming consensus about one draft-ie… Dr Stephen Henson
- Re: [TLS] Confirming consensus about one draft-ie… Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Michael D'Errico
- Re: [TLS] Confirming consensus about one draft-ie… Rex, Martin
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- [TLS] Metadiscussion on changes in draft-ietf-tls… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Marsh Ray
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Hovav Shacham
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Kemp, David P.
- Re: [TLS] Confirming consensus about one draft-ie… Nikos Mavrogiannopoulos
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Confirming consensus about one draft-ie… Yngve Nysaeter Pettersen
- [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Nelson B Bolyard
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Bob Braden
- Re: [TLS] Confirming consensus about one Michael D'Errico
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Marsh Ray
- Re: [TLS] Confirming consensus about one draft-ie… Robert Relyea
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Metadiscussion on changes in draft-ietf… Paul Hoffman
- [TLS] interoperability and security guarantees [w… Daniel Kahn Gillmor
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Chatter on consensus Michael D'Errico
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one Yoav Nir
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Chatter on consensus Kemp, David P.
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Confirming consensus about one Martin Rex
- Re: [TLS] Chatter on consensus Nikos Mavrogiannopoulos
- Re: [TLS] Metadiscussion on changes in draft-ietf… Pasi.Eronen
- Re: [TLS] Metadiscussion on changes in draft-ietf… Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Paul Hoffman
- Re: [TLS] Confirming consensus about one draft-ie… Martin Rex
- Re: [TLS] Chatter on consensus Martin Rex
- Re: [TLS] Confirming consensus about one draft-ie… Bill Frantz
- Re: [TLS] Confirming consensus about one draft-ie… tom.petch
- Re: [TLS] Confirming consensus about one draft-ie… Joseph Salowey (jsalowey)