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

Nicolas Williams <Nicolas.Williams@sun.com> Tue, 23 March 2010 20:56 UTC

Return-Path: <Nicolas.Williams@sun.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 D4C093A6C4C; Tue, 23 Mar 2010 13:56:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.39
X-Spam-Level:
X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[AWL=1.078, 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 0P9jZbafdzFI; Tue, 23 Mar 2010 13:56:46 -0700 (PDT)
Received: from rcsinet12.oracle.com (rcsinet12.oracle.com [148.87.113.124]) by core3.amsl.com (Postfix) with ESMTP id 018063A6C2E; Tue, 23 Mar 2010 13:56:45 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet12.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2NKux3f017159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 23 Mar 2010 20:57:04 GMT
Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2NKunpr010361; Tue, 23 Mar 2010 20:56:49 GMT
Received: from abhmt005.oracle.com by acsmt354.oracle.com with ESMTP id 104784801269377760; Tue, 23 Mar 2010 13:56:00 -0700
Received: from Sun.COM (/129.153.128.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 23 Mar 2010 13:56:00 -0700
Date: Tue, 23 Mar 2010 15:55:55 -0500
From: Nicolas Williams <Nicolas.Williams@sun.com>
To: Larry Zhu <larry.zhu@microsoft.com>
Message-ID: <20100323205554.GC21244@Sun.COM>
References: <20100317231522.GA18167@Sun.COM> <20100322232150.GB21244@Sun.COM> <20100323065301.GE21244@Sun.COM> <20100323190629.GR21244@Sun.COM> <4B17DE30119FF1429798D9F5D94BDE8C0EB563F1@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com> <20100323195956.GY21244@Sun.COM> <4B17DE30119FF1429798D9F5D94BDE8C0EB5667A@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4B17DE30119FF1429798D9F5D94BDE8C0EB5667A@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.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.0A090206.4BA92B1A.013D,ss=1,fgs=0
Cc: Mark Novak <Mark.Novak@microsoft.com>, "channel-binding@ietf.org" <channel-binding@ietf.org>, Pasi Eronen <pasi.eronen@nokia.com>, "tls@ietf.org" <tls@ietf.org>, "sasl@ietf.org" <sasl@ietf.org>
Subject: Re: [CHANNEL-BINDING] [TLS] [sasl] Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW)
X-BeenThere: channel-binding@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
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 20:56:46 -0000

On Tue, Mar 23, 2010 at 08:48:41PM +0000, Larry Zhu wrote:
> I briefly chatted with Sam who was in the tls-unique design/discussion
> meeting last Sunday. It turns out that the community as represented by
> key stake holders in that meeting believed that:
> 
> 1) TLS renegotiation is driven by TLS apps.
> 2) as the result, the apps can figure out, based on the app specific
> context, which TLS side will start renegotiation and when, e.g. in a
> locked-step fashion.
> 2) therefore it is acceptable to leave the behavior in the case of the
> described synchronization undefined.
> 
> If this does not capture the spirit of that discussion, please let me
> know. 

It does.  However, it does also mean that I had to write a bunch of
normative text in draft-altman-... to say that apps must do this.  That
strikes me as ugly complexity.

If you never have re-negotiation happening before authentication then
why do we need to worry about this?  -- that's my question.

> Shall we proceed with that and capture the discussion in the ID (that
> means another update to the ID).

I wrote -09 so as to capture that discussion.

>                                  Personally I am not aware of any new
> data points that would invalidate the above recommendation.

I'm asking questions about your implementation.  The answers to those
questions might actually bring new data points to light that, while they
wouldn't invalidate our earlier decision, might lead us to re-consider
that decision.

Nico
--