Re: [TLS] TLS renegotiation issue

Martin Rex <mrex@sap.com> Thu, 05 November 2009 18:48 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 79F5128C0E3 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 10:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 DPHnElOZgoL0 for <tls@core3.amsl.com>; Thu, 5 Nov 2009 10:48:05 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 434103A63EB for <tls@ietf.org>; Thu, 5 Nov 2009 10:48:05 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA5ImQY2021184 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 5 Nov 2009 19:48:26 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911051848.nA5ImQaY004909@fs4113.wdf.sap.corp>
To: ekr@rtfm.com (Eric Rescorla)
Date: Thu, 5 Nov 2009 19:48:26 +0100 (MET)
In-Reply-To: <d3aa5d00911051016p7a0cc508q2090b86de30a50d5@mail.gmail.com> from "Eric Rescorla" at Nov 5, 9 10:16:11 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: tls@ietf.org
Subject: Re: [TLS] TLS renegotiation issue
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, 05 Nov 2009 18:48:06 -0000

Eric Rescorla wrote:
> 
> I now have a draft extension up 

Thanks Eric.

  Page 5:

  The contents of this extension are specified as follows.
   [...]
  The above rules apply even when TLS resumption is used.


I read this as meaning that the client and server should add
two elements client.verify_data and server.verify_data
to their SecurityParameters for the connection state suggested
by RFC5246 6.1. and update this data on EVERY TLS handshake,
even TLS session resume.


  4.1  Client Considerations

I can understand what it says, but I _really_ dislike it.

The root of the problem is servers that perform (or at least allow)
TLS renegotiations and make flawed assumptions about what a
successful TLS renegotiation means for the data previously received.

What you're essentially asking for, is that a client should no longer
talk TLS to _any_ Server that doesn't support the new extension.
Not even to the good ones that neither offer nor support renegotiation.

This is discriminating against servers that have been playing safe!

Essentially we are going to hold TLS clients and the installed
base of good Servers responsible for the broken Servers out there.
That feels very wrong.


-Martin

PS:

>
> https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

That URL results in a cert warning in my Firefox browser.
Following the Client considerations, I feel much safer
removing the "s" in "https" in the URL than trying to add
an exception for the servers certificate...  ;-)