Re: [TLS] Quest for Unified Solution to TLS Renegotiation

Martin Rex <mrex@sap.com> Thu, 26 November 2009 01:02 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 298D33A68B3 for <tls@core3.amsl.com>; Wed, 25 Nov 2009 17:02:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.169
X-Spam-Level:
X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.080, 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 jnZP-nsarXDk for <tls@core3.amsl.com>; Wed, 25 Nov 2009 17:02:29 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 265583A67BD for <tls@ietf.org>; Wed, 25 Nov 2009 17:02:28 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nAQ12LDq022067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 Nov 2009 02:02:21 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <200911260102.nAQ12KhK009382@fs4113.wdf.sap.corp>
To: ekr@networkresonance.com
Date: Thu, 26 Nov 2009 02:02:20 +0100
In-Reply-To: <20091125232446.24F2A6C32B0@kilo.networkresonance.com> from "Eric Rescorla" at Nov 25, 9 03:24:45 pm
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] Quest for Unified Solution to TLS Renegotiation
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, 26 Nov 2009 01:02:30 -0000

Eric Rescorla wrote:
> 
> At Wed, 25 Nov 2009 15:19:51 -0800,
> Michael D'Errico wrote:
> > The complaint I have about sending the verify_data over the wire is
> > that that alone does not plug the hole.  You need to take the extra
> > step to check that it's correct, and a maintenance programmer not
> > intimately familiar with TLS might miss this fact.
> 
> I don't find this argument very compelling. There are all sorts of
> ways to screw up your TLS implementation that are worse than this
> and are difficult/impossible to detect from the other side. E.g.,

The compelling reason is, that when we define TLSv1.3 then we
could stop sending the TLS extension RI entirely for TLS sessions
negotiated to use TLSv1.3.

If we use the band-aid TLS-extension-RI-with-verify-data to put the
verify data from the last handshake into the renegotiation, we will
need to contine apply this band-aid eternally.


-Martin