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