Re: [TLS] draft-ietf-tls-renegotation: next
Martin Rex <mrex@sap.com> Thu, 17 December 2009 18:58 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 4E9283A694D for <tls@core3.amsl.com>; Thu, 17 Dec 2009 10:58:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.196
X-Spam-Level:
X-Spam-Status: No, score=-6.196 tagged_above=-999 required=5 tests=[AWL=0.053, 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 MjM9m1dNg4Pf for <tls@core3.amsl.com>; Thu, 17 Dec 2009 10:58:34 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.171]) by core3.amsl.com (Postfix) with ESMTP id 469E13A69C1 for <tls@ietf.org>; Thu, 17 Dec 2009 10:58:34 -0800 (PST)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id nBHIwHjw029872 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Dec 2009 19:58:17 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200912171858.nBHIwG5H008367@fs4113.wdf.sap.corp>
To: marsh@extendedsubset.com
Date: Thu, 17 Dec 2009 19:58:16 +0100
In-Reply-To: <4B296ABD.8050403@extendedsubset.com> from "Marsh Ray" at Dec 16, 9 05:18:21 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal06
X-SAP: out
Cc: tls@ietf.org
Subject: Re: [TLS] draft-ietf-tls-renegotation: next
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, 17 Dec 2009 18:58:35 -0000
Marsh Ray wrote: > > > But as I described, > > these are going to be servers that do not renegotiate anyway, > > TLS does not define such a thing as a "server that does not > renegotiate". There may be in fact some application protocols or servers > which do not, but TLS provide no way to indicate this in the handshake. As evident from rfc-5246 Appendix D. renegotiation is an optional feature of the SSLv3/TLS protocol family and not available in all implementations of SSLv3/TLS. Since you are still listed as an author of the spec, I consider your interpretation fairly authoritative for what the spec intends to say. --which means that there is a defect, because it does currently _not_ specify the behaviour for non-renegotiating servers (which you incorrectly assumed to not exist). Please fix this defect _before_ publishing this specification. The only reason why secure TLS renegotiation can be considered an update to the existing installed base at all (and not a different non-interoperable protocol), is that renegotiation has never been a core element of SSLv3/TLS and is optional-to-implement. Essentially, the secure renegotiation spec is deprecating the old renegotiation and defining a new, optional, secure renegotiation. Describing potential vulnerabilities from using backwards-interoble renegotiation with the installed base and discouraging the use of that old optional feature is fine. Encouraging the use the new optional and secure renegotiation is also no problem. Describing security implications of old TLS peers that still offer old renegotiation is also no problem. Discouraging the interoperability with compliant but not updated SSLv3->TLSv1.2 on the core protocol elements (aka initial TLS handshake) is inacceptable, because it would make updated TLS peers non-compliant with the original TLS spec, which implies these peers are using a different protocol. -Martin
- [TLS] draft-ietf-tls-renegotation: next steps Pasi.Eronen
- Re: [TLS] draft-ietf-tls-renegotation: next steps Martin Rex
- Re: [TLS] draft-ietf-tls-renegotation: next steps Paul Hoffman
- Re: [TLS] draft-ietf-tls-renegotation: next steps Michael D'Errico
- Re: [TLS] draft-ietf-tls-renegotation: next steps Martin Rex
- Re: [TLS] draft-ietf-tls-renegotation: next steps Marsh Ray
- Re: [TLS] draft-ietf-tls-renegotation: next steps Eric Rescorla
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Kemp, David P.
- Re: [TLS] draft-ietf-tls-renegotation: next steps Marsh Ray
- Re: [TLS] draft-ietf-tls-renegotation: next steps Martin Rex
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Martin Rex
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Marsh Ray
- [TLS] Generic process issues (Re: Re: draft-ietf-… Nicolas Williams
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Martin Rex
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Martin Rex
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Marsh Ray
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Martin Rex
- Re: [TLS] draft-ietf-tls-renegotation: next steps David-Sarah Hopwood
- Re: [TLS] draft-ietf-tls-renegotation: next steps David-Sarah Hopwood
- Re: [TLS] draft-ietf-tls-renegotation: next steps Martin Rex
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Marsh Ray
- Re: [TLS] draft-ietf-tls-renegotation: next Pasi.Eronen
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Martin Rex
- Re: [TLS] [POSSIBLE SPAM] Re: draft-ietf-tls-rene… Martin Rex
- Re: [TLS] draft-ietf-tls-renegotation: next Martin Rex
- Re: [TLS] draft-ietf-tls-renegotation: next Martin Rex
- Re: [TLS] draft-ietf-tls-renegotation: next Marsh Ray
- Re: [TLS] draft-ietf-tls-renegotation: next Kyle Hamilton
- Re: [TLS] draft-ietf-tls-renegotation: next Martin Rex
- Re: [TLS] draft-ietf-tls-renegotation: next Michael D'Errico
- Re: [TLS] draft-ietf-tls-renegotation: next David-Sarah Hopwood