Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard
Bodo Moeller <bmoeller@acm.org> Mon, 30 November 2009 21:10 UTC
Return-Path: <SRS0=PRUA=HS=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12053A69D5; Mon, 30 Nov 2009 13:10:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.236
X-Spam-Level:
X-Spam-Status: No, score=-102.236 tagged_above=-999 required=5 tests=[AWL=0.014, BAYES_00=-2.599, HELO_EQ_DE=0.35, USER_IN_WHITELIST=-100]
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 cob3EMDDlFqi; Mon, 30 Nov 2009 13:10:14 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id A3CE93A69D3; Mon, 30 Nov 2009 13:10:13 -0800 (PST)
Received: from bmoeller-macbookpro.fritz.box (77-57-209-74.dclient.hispeed.ch [77.57.209.74]) by mrelayeu.kundenserver.de (node=mrbap1) with ESMTP (Nemesis) id 0MQM9c-1Ngknn0mya-00UIvP; Mon, 30 Nov 2009 22:10:03 +0100
From: Bodo Moeller <bmoeller@acm.org>
To: ietf@ietf.org
In-Reply-To: <20091130153734.D44C63A6AA9@core3.amsl.com>
Subject: Re: [TLS] Last Call: draft-ietf-tls-renegotiation (Transport Layer Security (TLS) Renegotiation Indication Extension) to Proposed Standard
References: <20091130153734.D44C63A6AA9@core3.amsl.com>
Message-Id: <F9E79A35-0360-401E-8D45-80589BFCDC98@acm.org>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Mon, 30 Nov 2009 22:10:02 +0100
X-Mailer: Apple Mail (2.936)
X-Provags-ID: V01U2FsdGVkX1+1TCuAPeejR7YT2j0Dv5I9JUG0FJ0cNya1xX/ yZlhROCVMP6sB/vsqS1jxblpxv/15x5WgEXLQ2yhFSun9xS0y7 eMgaeB9rlJzKrPtbLKOCQ==
X-Mailman-Approved-At: Tue, 01 Dec 2009 08:31:01 -0800
Cc: "tls@ietf.org Working Group" <tls@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2009 21:13:43 -0000
On Nov 30, 2009, at 4:37 PM, The IESG wrote: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > > - 'Transport Layer Security (TLS) Renegotiation Indication Extension ' > <draft-ietf-tls-renegotiation-01.txt> as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the > ietf@ietf.org mailing lists by 2009-12-14. I support the move, contingent to two clean-ups to specified behavior: 1. Section 3 specifies "For ClientHellos which are renegotiating, this field contains the verify_data from the Finished message sent by the client on the immediately previous handshake", and "For ServerHellos which are renegotiating, this field contains the concatenation of the verify_data values sent by the client and the server (in that order) on the immediately previous handshake." There is no good reason for this asymmetry of having just the client's verify_data in the client's message, but both the client's and the server's verify_data in the server's message -- the latter is pure overhead, both in the specification and in the on-the-wire protocol. To remove the overhead from both, the second sentence should be saying, "For ServerHellos which are renegotiating, this field contains the verify_data sent by the server on the immediately previous handshake" (according changes to dependent parts of the specification then should be made). For earlier Internet Drafts in the series preceding draft-ietf-tls- renegotiation-01.txt (draft-rescorla-tls-renegotiation.00.txt, etc.), a reason to keep the current text would have been to maintain compatibility with early implementations of those Internet Drafts. However, draft-ietf-tls-renegotiation-01 has a newer TLS_RENEGO_PROTECTION_REQUEST cipher suite and thus breaks compatibility with those early implementations anyway. (This means that now, changing the ServerHello extension definition as suggested above gives the beneficial side-effect of exposing premature implementations, besides merely avoiding overhead. Those incomplete implementations will be more obviously incompatible because they'd still be using the protocol variant with overhead, instead of just differing subtly in the behavior if faced with TLS_RENEGO_PROTECTION_REQUEST.) 2. The Security Considerations section of draft-ietf-tls- renegotiation-01.txt (section 7) includes language that unnecessarily restricts the flexibility that the TLS protocol specifically provides for, regulating areas that the TLS standard intentionally does not specify (RFC 5246 section 1) -- the current Internet Draft says: "By default, TLS implementations conforming to this document MUST verify that once the peer has been identified and authenticated within the TLS handshake, the identity does not change on subsequent renegotiations. For certificate based cipher suites, this means bitwise equality of the end-entity certificate. If the other end attempts to authenticate with a different identity, the renegotiation MUST fail. If the server_name extension is used, it MUST NOT change when doing renegotiation." There is no security reason for this restriction. This sounds like a bad and incomplete workaround for certain problems with TLS that the updated protocol does not need a workaround for at all, because the protocol update is all about properly *solving* those problems. Keeping this language in the specification would have the weird implication that applications that *need* the flexibility provided by the TLS protocol (e.g., to allow renegotiation handshakes to switch to a different ciphersuite, which may require a different certificate) would have to to *skip* implementing the protocol update, and thus stay vulnerable. The new restriction that draft-ietf-tls-renegotiation-01.txt tries to sneak in thus seems harmful both for interoperability and for security. I haven't seen any signs of working group consensus on including this new restriction. Bodo
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Martin Rex
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Martin Rex
- RE: [TLS] Last Call: draft-ietf-tls-renegotiation… Robert Dugal
- RE: [TLS] Last Call: draft-ietf-tls-renegotiation… Glen Zorn
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Yoav Nir
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Stephen Farrell
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Bodo Moeller
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… David-Sarah Hopwood
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Marsh Ray
- RE: [TLS] Last Call: draft-ietf-tls-renegotiation… Nasko Oskov
- RE: [TLS] Last Call: draft-ietf-tls-renegotiation… Rob P Williams
- RE: [TLS] Last Call: draft-ietf-tls-renegotiation… Joseph Salowey (jsalowey)
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Stefan Santesson
- NOT RECOMMENDED (was: Re: [TLS] Last Call: draft-… Peter Saint-Andre
- RE: NOT RECOMMENDED (was: Re: [TLS] Last Call:dra… Dan Wing
- Re: Last Call: draft-ietf-tls-renegotiation (Tran… Chris Newman
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Yoav Nir
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Chris Newman
- Re: NOT RECOMMENDED Bob Braden
- Re: NOT RECOMMENDED Dave CROCKER
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Chris Newman
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Tom.Petch
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Cullen Jennings
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Marsh Ray
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Martin Rex
- RE: [TLS] Last Call: draft-ietf-tls-renegotiation… peter.robinson
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Martin Rex
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Nelson B Bolyard
- Re: Last Call: draft-ietf-tls-renegotiation (Tran… Florian Weimer
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Steve Checkoway
- RE: [TLS] Last Call: draft-ietf-tls-renegotiation… Glen Zorn
- Re: [TLS] Last Call: draft-ietf-tls-renegotiation… Martin Rex
- Re: Last Call: draft-ietf-tls-renegotiation (Tran… Tom.Petch