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 (MET)
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