IETF Logo Mail Archive

Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer

Martin Rex <mrex@sap.com> Wed, 02 December 2009 03:29 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 373223A6774 for <tls@core3.amsl.com>; Tue, 1 Dec 2009 19:29:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.191
X-Spam-Level:
X-Spam-Status: No, score=-6.191 tagged_above=-999 required=5 tests=[AWL=0.058, 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 wOrPswr5Rxf1 for <tls@core3.amsl.com>; Tue, 1 Dec 2009 19:29:35 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 2C31C3A682D for <tls@ietf.org>; Tue, 1 Dec 2009 19:29:35 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nB23TNUi017554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 2 Dec 2009 04:29:23 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912020329.nB23TMcL010059@fs4113.wdf.sap.corp>
To: aerowolf@gmail.com
Date: Wed, 02 Dec 2009 04:29:22 +0100
In-Reply-To: <6b9359640911301019w114a2a46m32c16afb2cb26067@mail.gmail.com> from "Kyle Hamilton" at Nov 30, 9 10:19:45 am
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal08
X-SAP: out
Cc: ekr@rtfm.com, tls@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer
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: Wed, 02 Dec 2009 03:29:36 -0000

Kyle Hamilton wrote:
> 
> What I'm seeing here:
> 
> An implementation continues to be conformant to TLS even if the RI
> isn't sent.  If a client doesn't send the RI (either cipher suite flag
> or extension), the server can't send the RI extension back (as it's a
> violation of TLS 1.2 for a server to send an unsolicited extension).
> If a client does send the RI cipherflag or extension, the server may
> send back the RI reply, or (if its security policy prohibits
> renegotiation -- to reduce the possible impact of large numbers of
> reneg's overwhelming any crypto implementation, or because it's known
> that client certificates are never going to be solicited by the
> server, to name a couple of possible reasons) it may choose not to
> reply with the extension.

It has been previously mentioned: this is likely an insufficiently
clear wording of the spec.

The TLS_RENEGO_PROTECTION_REQUEST cipher suite value is _not_
a means to request secure renegotiation (for the TLS extension RI,
only the extension containing the verify_data is such a request).

The purpose of the magic cipher suite is a request for protection
from the _INsecure_ or "old" renegotiation.

The spec should explicitly say that every updated/conforming client
MUST add that cipher suite value into every ClientHello handshake
message that it sends out, and that includes clients that do not
implement renegotiation or have it disabled.  That decision MUST
be free from policy and configuration.


In the attack scenario depicted in the document, the client only
sees an initial TLS handshake an no renegotiation.


The same applies to the servers.   The document should explicitly
say that servers MUST return the empty TLS renegotiation when
the client requested it (by including the magic cipher suite value
in the ClientHello).  That includes servers that do not implement
renegotiation or have it disabled.  That decision MUST be free
from policy and configuration.



-Martin

v2.23.0 | Report a Bug | By Email