Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to

Martin Rex <mrex@sap.com> Tue, 23 March 2010 23:14 UTC

Return-Path: <mrex@sap.com>
X-Original-To: channel-binding@core3.amsl.com
Delivered-To: channel-binding@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543323A6D20; Tue, 23 Mar 2010 16:14:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.119
X-Spam-Level:
X-Spam-Status: No, score=-9.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 ViXlouGHFsuM; Tue, 23 Mar 2010 16:14:17 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4D7F13A6D1E; Tue, 23 Mar 2010 16:14:17 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id o2NNEZto000117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Mar 2010 00:14:35 +0100 (MET)
From: Martin Rex <mrex@sap.com>
Message-Id: <201003232314.o2NNEX6n002849@fs4113.wdf.sap.corp>
To: larry.zhu@microsoft.com
Date: Wed, 24 Mar 2010 00:14:33 +0100
In-Reply-To: <4B17DE30119FF1429798D9F5D94BDE8C0EB567FF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> from "Larry Zhu" at Mar 23, 10 09:07:12 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal07
X-SAP: out
Cc: Mark.Novak@microsoft.com, channel-binding@ietf.org, Nicolas.Williams@sun.com, pasi.eronen@nokia.com, tls@ietf.org, sasl@ietf.org
Subject: Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to
X-BeenThere: channel-binding@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
List-Id: Discussion of channel binding IANA registry requests and specifications <channel-binding.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/channel-binding>
List-Post: <mailto:channel-binding@ietf.org>
List-Help: <mailto:channel-binding-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/channel-binding>, <mailto:channel-binding-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Mar 2010 23:14:18 -0000

Larry Zhu wrote:
> 
> It is amusing that if you actually suggest that it is more complex
> to leave the behavior as undefined.

The part that is a little funny (or weird) is something else.

When we realized that the original TLS renegotiation resulted,
in fact, in a completely different and unrelated channel than
its predecessor, and that all apps that blindly assumed it
would be still the same channel, we decided to fix TLS and
provide that assurance to the app.

_After_ fixing TLS renegotiation, it sounds strange to
define TLS channel bindings that clearly indicate that the
channel before TLS renegotiation and after TLS renegotiation
is _NOT_ the same channel (because it uses different channel
bindings and will make authentications fail that mix them up).

That is IMHO a little weird.


-Martin