Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 23 March 2010 21:26 UTC

Return-Path: <Nicolas.Williams@sun.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 072C43A6C5A; Tue, 23 Mar 2010 14:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.794
X-Spam-Level:
X-Spam-Status: No, score=-4.794 tagged_above=-999 required=5 tests=[AWL=0.674, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
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 47Jx12wpCyiw; Tue, 23 Mar 2010 14:26:13 -0700 (PDT)
Received: from acsinet11.oracle.com (acsinet11.oracle.com [141.146.126.233]) by core3.amsl.com (Postfix) with ESMTP id 1A4183A6C45; Tue, 23 Mar 2010 14:26:13 -0700 (PDT)
Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2NLQN7C010375 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Mar 2010 21:26:30 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2NLQMqx016415; Tue, 23 Mar 2010 21:26:22 GMT
Received: from abhmt004.oracle.com by acsmt354.oracle.com with ESMTP id 104863271269379494; Tue, 23 Mar 2010 14:24:54 -0700
Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Mar 2010 14:24:53 -0700
Date: Tue, 23 Mar 2010 16:24:48 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: channel-binding@ietf.org, sasl@ietf.org, tls@ietf.org, Mark Novak <Mark.Novak@microsoft.com>, Larry Zhu <lzhu@wollive.windowsmedia.com.akadns.net>
Message-ID: <20100323212448.GF21244@Sun.COM>
References: <20100317231522.GA18167@Sun.COM> <20100322232150.GB21244@Sun.COM> <20100323065301.GE21244@Sun.COM> <20100323190629.GR21244@Sun.COM>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20100323190629.GR21244@Sun.COM>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Source-IP: acsmt354.oracle.com [141.146.40.154]
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090208.4BA931FF.011A,ss=1,fgs=0
Cc: Pasi Eronen <pasi.eronen@nokia.com>
Subject: Re: [TLS] [CHANNEL-BINDING] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)
X-BeenThere: tls@ietf.org
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." <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: Tue, 23 Mar 2010 21:26:14 -0000

On Tue, Mar 23, 2010 at 02:06:29PM -0500, Nicolas Williams wrote:
> It occurs to me that it must be very unlikely that any apps using the
> MSFT variant of tls-unique are doing authentication after TLS
> re-negotiation.  We already have confirmation that in the HTTP/Negotiate
> case that never happens.  If so, might you be willing to fix your
> implementation to always use the initial handshake?  That would help
> remove two pieces of complexity from -09: a) security considerations with
> regard to the TLS re-negotiation bug, b) interoperability considerations
> with regard to the channel binding synchronization problem.

I need to re-word my question to clarify that I'm not interested in
knowing what MSFT proprietary apps you're using CB in.  Does TLS
re-negotiation ever occur prior to authentication in any of your
applications?  I'm NOT interested in knowing anything else about
proprietary MSFT applications, just that one detail about Internet as
well as proprietary apps.

The point of the question is to establish whether we really have to pick
the first Finished message of the latest/inner-most handshake or if
there's still time for you to fix your implementation so that we can use
the first Finished message of the first/outer-most handshake.

Nico
--