[TLS] Avoiding CB sync problem via server-side solution (was Re: Updates to draft-altman-tls-channel-bindings, take two (PLEASE REVIEW))

Nicolas Williams <Nicolas.Williams@Sun.COM> Wed, 24 March 2010 21:29 UTC

Return-Path: <Nicolas.Williams@Sun.COM>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 120853A6A3A; Wed, 24 Mar 2010 14:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.929
X-Spam-Status: No, score=-4.929 tagged_above=-999 required=5 tests=[AWL=0.539, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id J0zp1Tioqg-Q; Wed, 24 Mar 2010 14:29:14 -0700 (PDT)
Received: from acsinet11.oracle.com (acsinet11.oracle.com []) by core3.amsl.com (Postfix) with ESMTP id AFBA93A69ED; Wed, 24 Mar 2010 14:29:13 -0700 (PDT)
Received: from acsinet15.oracle.com (acsinet15.oracle.com []) by acsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2OLTWAC004429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 24 Mar 2010 21:29:33 GMT
Received: from acsmt355.oracle.com (acsmt355.oracle.com []) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2OJCTCp005211; Wed, 24 Mar 2010 21:29:29 GMT
Received: from abhmt018.oracle.com by acsmt354.oracle.com with ESMTP id 108169001269466114; Wed, 24 Mar 2010 14:28:34 -0700
Received: from Sun.COM (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 24 Mar 2010 14:28:34 -0700
Date: Wed, 24 Mar 2010 16:28:30 -0500
From: Nicolas Williams <Nicolas.Williams@Sun.COM>
To: Simon Josefsson <simon@josefsson.org>
Message-ID: <20100324212829.GA21244@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> <87r5napxjn.fsf@mocca.josefsson.org> <20100323205807.GD21244@Sun.COM> <87hbo6px85.fsf@mocca.josefsson.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87hbo6px85.fsf@mocca.josefsson.org>
User-Agent: Mutt/1.5.20 (2010-03-02)
X-Source-IP: acsmt355.oracle.com []
X-Auth-Type: Internal IP
X-CT-RefId: str=0001.0A090203.4BAA843C.003F,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: [TLS] Avoiding CB sync problem via server-side solution (was Re: 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: Wed, 24 Mar 2010 21:29:15 -0000

On Tue, Mar 23, 2010 at 10:03:06PM +0100, Simon Josefsson wrote:
> Nicolas Williams <Nicolas.Williams@sun.com> writes:
> > But what is the trigger?  Key aging?
> A renegotiation request from the peer, as I understood it.

The peer being the TLS server.  What's the trigger on the server side?

In most apps authentication happens soon after establishing the channel,
so re-keying as a trigger is out of the question.  That leaves TLS
authentication using a user cert, which is a form of authentication in
itself, and which the server application ought not request
asynchronously from application-layer authentication.

It's possible that in practice we never authenticate before
re-negotiation because the server doesn't ever need to request
re-negotiation before authentication.  The spec would still need
significant amounts of verbiage about this situation, but at least
avoiding the situation would be much easier because avoidance could be
done using existing APIs on the server-side instead of requiring new
APIs on the client side.

(Of course, if it never happens, then it seems much less necessary to
change the spec for tls-unique to say that re-negotiation changes the
channel's CB.  But it might turn out to always happen for future app
protocols, in which case a discrepancy amongst implementors would be
bad.  Also, there exist SASL apps allow for re-authentication at any
time, so we must agree on one approach.)

I'm much more comfortable with avoiding the CB synchronization problem
by using existing APIs on the server side.  Do we agree that this is
possible and desirable?  If so I'll make the change.