Re: [TLS] TLS renegotiation issue

Martin Rex <> Thu, 05 November 2009 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 79F5128C0E3 for <>; Thu, 5 Nov 2009 10:48:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.949
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DPHnElOZgoL0 for <>; Thu, 5 Nov 2009 10:48:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 434103A63EB for <>; Thu, 5 Nov 2009 10:48:05 -0800 (PST)
Received: from by (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 <>
Message-Id: <>
To: (Eric Rescorla)
Date: Thu, 5 Nov 2009 19:48:26 +0100 (MET)
In-Reply-To: <> 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
Subject: Re: [TLS] TLS renegotiation issue
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.




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...  ;-)