Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation
Martin Rex <mrex@sap.com> Tue, 26 January 2010 17:57 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 3C0643A697A; Tue, 26 Jan 2010 09:57:17 -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 GykAJQdGp1pf; Tue, 26 Jan 2010 09:57:16 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 086663A696F; Tue, 26 Jan 2010 09:57:15 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id o0QHvP4N019555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Jan 2010 18:57:25 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201001261757.o0QHvOXd024945@fs4113.wdf.sap.corp>
To: tls@ietf.org
Date: Tue, 26 Jan 2010 18:57:24 +0100
In-Reply-To: <808FD6E27AD4884E94820BC333B2DB775841199A56@NOK-EUMSG-01.mgdnok.nokia.com> from "Pasi.Eronen@nokia.com" at Jan 26, 10 09:49:06 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: ietf@ietf.org
Subject: Re: [TLS] Confirming consensus about one draft-ietf-tls-renegotiation
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, 26 Jan 2010 17:57:17 -0000
Pasi.Eronen@nokia.com wrote: > > The detail in question is whether the "Signalling Cipher Suite Value" > (SCSV) can be included when performing secure renegotiation (in > addition to the renegotiation_info extension). > > Currently, the SCSV is not included. In the version that went to IETF > Last Call (version -01), the relevant text was: > > "This cipher suite has exactly the same semantics as an empty > "renegotiation_info" extension. [..] Because this cipher suite is > equivalent to an empty "renegotiation_info" extension, only > "renegotiation_info" may be used rehandshakes." (in Section 4) > > Version -03 (the latest version) has rephrased the text as follows: > > "The SCSV MUST NOT be included." (in Section 3.5, "Client Behavior: > Secure Renegotiation") > > "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." (in Section 3.7, > "Server Behavior: Secure Renegotiation") http://tools.ietf.org/html/rfc2119#section-6 6. Guidance in the use of these Imperatives^M Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. The two MUST NOTs that popped up in -03 are in violation of rfc2119 section 6! Keep in mind that sending SCSV on renegotiations is explicitly permitted by -03 for old renegotiations so that is inconsistent. Further inconsistencies: section 3.3 says "the SCSV may be safely be sent to any server". which obviously contradicts both new MUST NOTs. I think we all agree that using a cipher suite value for signaling is a creative use ("hack") of a TLS protocol extensibility option that is not documented in this fashion in SSL/TLS. By doing this, we should limit the changes of the semantics of this extensibility option to the absolute necessary. There never was an interop problem based on a presence of a particular cipher suite value in TLS, and it doesn't seem like a good idea to create such an interop problem for the presence of a cipher suite value in ClientHello when it is avoidable. It can be easily avoided The WG discussion just before XMas developed consensus on how to do this. Did anyone of you review the new sections in the -03 draft? Question to those who are voicing opinions just now, what would you tell someone who has little TLS experience and just read the -03 document, to which attack this paragraph in -03 refers (section 4.2, bottom of page 9): http://tools.ietf.org/html/draft-ietf-tls-renegotiation-03#page-9 and to which "above attack" section 4.3 on page 10 refers? section 4.2, is not only confusing, it is also inconsistent. However, the attack will be detected by the client when the server sends an empty "renegotiation_info" extension and the client is expecting one containing the previous verify data. contradicts When the ServerHello is received, the client MUST verify that it does not contain the "renegotiation_info" extension. If it does, the client MUST abort the handshake. [Because the server has already indicated it does not support secure renegotiation the only way that this can happen is if the server is broken or there is an attack.] I do not think that rushing the document out of the door as-is would be a good idea. This would set new lows for the level of IETF Proposed Standard. *I* have never suggested and do not endorse the specific SCSV semantics as described in the -03 document. -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)